From struts-dev-joseph67@example.org Tue Jul 01 13:17:59 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 1581 invoked from network); 1 Jul 2003 13:17:58 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 13:17:58 -0000 Received: (qmail 9395 invoked by uid 97); 1 Jul 2003 13:20:22 -0000 Delivered-To: joseph67@example.org Received: (qmail 9388 invoked from network); 1 Jul 2003 13:20:22 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 13:20:22 -0000 Received: (qmail 864 invoked by uid 500); 1 Jul 2003 13:17:48 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 799 invoked from network); 1 Jul 2003 13:17:47 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 13:17:47 -0000 Received: (qmail 9372 invoked by uid 50); 1 Jul 2003 13:20:11 -0000 Date: 1 Jul 2003 13:20:11 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21223] New: - Grammatical error X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21223>. 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=21223 Grammatical error Summary: Grammatical error Product: Struts Version: Unknown Platform: All URL: http://jakarta.apache.org/struts/userGuide/introduction. html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Web Site AssignedTo: joseph67@example.org ReportedBy: joseph67@example.org 1.3 Struts Control Flow Struts is designed to makes it easy ... should read Struts is designed to make it easy ... --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 13:28:02 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 27020 invoked from network); 1 Jul 2003 13:28:01 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 13:28:01 -0000 Received: (qmail 9674 invoked by uid 97); 1 Jul 2003 13:30:25 -0000 Delivered-To: joseph67@example.org Received: (qmail 9667 invoked from network); 1 Jul 2003 13:30:25 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 13:30:25 -0000 Received: (qmail 16261 invoked by uid 500); 1 Jul 2003 13:26:14 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 16185 invoked from network); 1 Jul 2003 13:26:12 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 13:26:12 -0000 Received: (qmail 9609 invoked by uid 50); 1 Jul 2003 13:28:36 -0000 Date: 1 Jul 2003 13:28:36 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21224] New: - race condition in LookupDispatchAction.execute X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21224>. 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=21224 race condition in LookupDispatchAction.execute Summary: race condition in LookupDispatchAction.execute Product: Struts Version: Nightly Build Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Standard Actions AssignedTo: joseph67@example.org ReportedBy: joseph67@example.org This bug is in version 1.1 release. I found it by reading source code. I did not reproduce it, because it is a race condition, potentially very hard to reproduce. The race condition may occur if - two HTTP requests are serviced concurrently - both requests use the same locale - both requests use an action based on LookupDispatchAction - LookupDispatchAction.localeMap does not contain yet a map for the locale in question The race condition should have the following effect: one of the HTTP requests will use an empty map for the reverse-mapping of the submit button value into a message key. To understand this, consider a concurrent execution on behalf of two HTTP requests of the following code. Assume that both requests use the same locale, and that LookupDispatchAction.localeMap does not contain yet a map for this locale: In method execute in LookupDispatchAction: 206 synchronized (localeMap) { 207 lookupMap = (Map) this.localeMap.get(userLocale); 208 if (lookupMap == null) { 209 newLookupMap = true; 210 lookupMap = new HashMap(); 211 this.localeMap.put(userLocale, lookupMap); 212 } 213 } - this critical section was first executed by HTTP request 1. This request found lookupMap == null, and therefore set newLookupMap = true, and inserted a new, empty HashMap into localeMap. - then, the critical section was executed by HTTP request 2. Because request 1 inserted an object into localeMap, at key userLocal, request 2 found lookupMap != null. As a result, for request 2 we have newLookupMap = false. The code continues as follows: 214 215 synchronized (lookupMap) { 216 if (newLookupMap) { <<< Here, we insert content into lookupMap >>> 245 } This critical section is first executed by request 2. lookupMap receives no content, because newLookupMap is empty. At this point, request 2 is ready to use an empty lookup map, and fail to dispatch the request to the relevant method. Voila, the race condition occured. --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 14:09:12 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 26418 invoked from network); 1 Jul 2003 14:09:11 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:09:11 -0000 Received: (qmail 11076 invoked by uid 97); 1 Jul 2003 14:11:35 -0000 Delivered-To: joseph67@example.org Received: (qmail 11069 invoked from network); 1 Jul 2003 14:11:34 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 14:11:34 -0000 Received: (qmail 25670 invoked by uid 500); 1 Jul 2003 14:09:00 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 25658 invoked from network); 1 Jul 2003 14:08:59 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:08:59 -0000 Received: (qmail 11054 invoked by uid 50); 1 Jul 2003 14:11:24 -0000 Date: 1 Jul 2003 14:11:24 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21226] New: - misleading error message in LookupDispatchAction X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21226>. 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=21226 misleading error message in LookupDispatchAction Summary: misleading error message in LookupDispatchAction Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Standard Actions AssignedTo: joseph67@example.org ReportedBy: joseph67@example.org This bug is in Struts 1.1 release. DispatchAction and LookupDispatchAction emit the error message dispatch.parameter form bundle org.apache.struts.actions.LocalStrings The message says: Request[{0}] does not contain handler parameter named {1} The problem: the message will sometimes appear even though the handler parameter is present (it happens when the value of the parameter cannot be mapped onto a method name). Example: With the following declaration <action path="/updateArticle" type="sudety.UpdateArticleAction" parameter="actionKind" name="sudetyArt" scope="request"> (UpdateArticleAction extends LookupDispatchAction) I perform an HTTP GET on the following URI (relative to the context): /updateArticle.do?actionKind=foo and Tomcat says: The request sent by the client was syntactically incorrect (Request[/updateArticle] does not contain handler parameter named actionKind). This is wrong, because the request does contain parameter actionKind; the problem is with the value 'foo' of the parameter, which does not correspond with any method. Suggestion: In the case of LookupDispatchAction, I suggest that three different error messages be reported, depending on the situation: 1. The current message dispatch.parameter is OK when the parameter is absent 2. When the value of the parameter cannot be mapped onto a massage name in a bundle, we could use a message like this: dispatch.reversemap=In request[{0}], handler parameter named '{1}' has value '{2}', that cannot be mapped onto a message name in resource bundle {3} 3. When the name of the message cannot be mapped onto a method name, we could use a message like this (unless you can find something simpler): dispatch.finalmap=In request[{0}], handler parameter named '{1}' has value '{2}', that maps onto message name '{3}', and the latter cannot be mapped onto a method name. --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 14:21:09 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 61354 invoked from network); 1 Jul 2003 14:21:09 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:21:09 -0000 Received: (qmail 11678 invoked by uid 97); 1 Jul 2003 14:23:33 -0000 Delivered-To: joseph67@example.org Received: (qmail 11671 invoked from network); 1 Jul 2003 14:23:33 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 14:23:33 -0000 Received: (qmail 59915 invoked by uid 500); 1 Jul 2003 14:20:50 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 59852 invoked from network); 1 Jul 2003 14:20:49 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:20:49 -0000 Received: (qmail 11654 invoked by uid 50); 1 Jul 2003 14:23:14 -0000 Date: 1 Jul 2003 14:23:14 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21226] - Misleading error message in LookupDispatchAction X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21226>. 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=21226 Misleading error message in LookupDispatchAction joseph67@example.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement Summary|misleading error message in |Misleading error message in |LookupDispatchAction |LookupDispatchAction --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 14:31:22 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 94226 invoked from network); 1 Jul 2003 14:31:22 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:31:22 -0000 Received: (qmail 12120 invoked by uid 97); 1 Jul 2003 14:33:46 -0000 Delivered-To: joseph67@example.org Received: (qmail 12112 invoked from network); 1 Jul 2003 14:33:46 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 14:33:46 -0000 Received: (qmail 93493 invoked by uid 500); 1 Jul 2003 14:31:12 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 93480 invoked from network); 1 Jul 2003 14:31:12 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:31:12 -0000 Received: (qmail 12078 invoked by uid 50); 1 Jul 2003 14:33:37 -0000 Date: 1 Jul 2003 14:33:37 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21230] New: - 1.0.2 still listed as current stable release X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21230>. 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=21230 1.0.2 still listed as current stable release Summary: 1.0.2 still listed as current stable release Product: Struts Version: 1.1RC2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: joseph67@example.org ReportedBy: joseph67@example.org Unclear to me what the current stable release of struts is. Jakarta's June 29th news item says it is 1.1 (http://jakarta.apache.org/site/news.html#20030629.1). Struts home page indicates it is 1.1 in the left hand menu (http://jakarta.apache.org/struts/). The learning Struts page indicates it is 1.0.2 (http://jakarta.apache.org/struts/learning.html). The Struts status page indicates it is 1.0.2 (http://jakarta.apache.org/struts/news/index.html). Bugzilla has no 1.1 Final for the Version, just the release candidates. --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 14:34:17 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 2370 invoked from network); 1 Jul 2003 14:34:17 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:34:17 -0000 Received: (qmail 12233 invoked by uid 97); 1 Jul 2003 14:36:41 -0000 Delivered-To: joseph67@example.org Received: (qmail 12226 invoked from network); 1 Jul 2003 14:36:41 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 14:36:41 -0000 Received: (qmail 1709 invoked by uid 500); 1 Jul 2003 14:34:09 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 1697 invoked from network); 1 Jul 2003 14:34:09 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 14:34:09 -0000 Received: (qmail 12221 invoked by uid 50); 1 Jul 2003 14:36:34 -0000 Date: 1 Jul 2003 14:36:34 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21230] - 1.0.2 still listed as current stable release X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21230>. 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=21230 1.0.2 still listed as current stable release ------- Additional Comments From joseph67@example.org 2003-07-01 14:36 ------- The Struts Development Roadmap page incorrectly states: "Struts 1.1 Release Candidate 1 is in circulation and we are working toward a final release." See http://jakarta.apache.org/struts/status.html. --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 15:48:45 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 79419 invoked from network); 1 Jul 2003 15:48:45 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 15:48:45 -0000 Received: (qmail 16368 invoked by uid 97); 1 Jul 2003 15:51:11 -0000 Delivered-To: joseph67@example.org Received: (qmail 16361 invoked from network); 1 Jul 2003 15:51:10 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 15:51:10 -0000 Received: (qmail 78535 invoked by uid 500); 1 Jul 2003 15:48:36 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 78517 invoked from network); 1 Jul 2003 15:48:36 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 15:48:36 -0000 Received: (qmail 16356 invoked by uid 50); 1 Jul 2003 15:51:01 -0000 Date: 1 Jul 2003 15:51:01 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21235] New: - <html:radio>: Make value optional when idName is present X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21235>. 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=21235 <html:radio>: Make value optional when idName is present Summary: <html:radio>: Make value optional when idName is present Product: Struts Version: 1.1RC2 Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: joseph67@example.org ReportedBy: joseph67@example.org I want to render an array of values one of which should be selected via a <html:radio>. The value that should be sent to the server is the index in the array. This doesn't work easily as idName is supposed to be a bean, with the value attribute providing the property name. The code as it stands would already work except for the fact that value is marked as required in the TLD. Making it so only when idName is not present would support my use case. The workaround is to use a primitive scriptlet to render the value, but aren't tags supposed to eliminate that need? :-) <logic:iterate id="label" indexId="serverValue" name="labelsArray"> <html:radio property="currentValue" idName="serverValue" /> <bean:write name="label" /> </logic:iterate> This is report against 1.1RC2, but the problem is still there in 1.1 final. Congratulations to that, BTW! --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 16:02:37 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 16016 invoked from network); 1 Jul 2003 16:02:36 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 16:02:36 -0000 Received: (qmail 16814 invoked by uid 97); 1 Jul 2003 16:05:02 -0000 Delivered-To: joseph67@example.org Received: (qmail 16807 invoked from network); 1 Jul 2003 16:05:02 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 16:05:02 -0000 Received: (qmail 15393 invoked by uid 500); 1 Jul 2003 16:02:28 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 15380 invoked from network); 1 Jul 2003 16:02:28 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 16:02:28 -0000 Received: (qmail 16804 invoked by uid 50); 1 Jul 2003 16:04:54 -0000 Date: 1 Jul 2003 16:04:54 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Cc: Subject: DO NOT REPLY [Bug 21235] - <html:radio>: Make value optional when idName is present X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=21235>. 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=21235 <html:radio>: Make value optional when idName is present ------- Additional Comments From joseph67@example.org 2003-07-01 16:04 ------- Oops, sorry, I lied about the fix involving only a TLD update. After checking BaseHandlerTag.lookupProperty() I realize it requires the property. Thought this method would handle the normal struts convention of the property being optional. :-( --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:07:03 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 31061 invoked from network); 1 Jul 2003 17:07:02 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:07:02 -0000 Received: (qmail 19611 invoked by uid 97); 1 Jul 2003 17:09:29 -0000 Delivered-To: joseph67@example.org Received: (qmail 19604 invoked from network); 1 Jul 2003 17:09:28 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:09:28 -0000 Received: (qmail 4697 invoked by uid 500); 1 Jul 2003 17:01:19 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 4645 invoked from network); 1 Jul 2003 17:01:18 -0000 Received: from web11505.mail.yahoo.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:01:18 -0000 Message-ID: <joseph67@example.org> Received: from [83.161.120.155] by web11505.mail.yahoo.com via HTTP; Tue, 01 Jul 2003 10:01:22 PDT Date: Tue, 1 Jul 2003 10:01:22 -0700 (PDT) From: Jon Wilmoth <joseph67@example.org> Reply-To: joseph67@example.org Subject: Re: Support for Date datatypes!!! To: Struts Developers List <joseph67@example.org> In-Reply-To: <joseph67@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I agree the proposal was not a wholistic solution, but it did address an very real issue with a "doable" timeframe. Since every application I've every been involved with has had to solve date conversions, I believe this is an ideal extension to the framework. It should be noted that date support is provided through the default converters (org.apache.commons.beanutils.converters.SqlDateConverter, org.apache.commons.beanutils.converters.SqlTimeConverter, and org.apache.commons.beanutils.converters.SqlTimestampConverter) but they required a fixed input format that may not work with all application. I welcome a more universal solution (and have some thoughts for such outlined below), but I am afraid of getting into a design that due to it's numerous touch points never gets implemented. Perhaps I've just listened to one too many "Agile Methodology" pitches ;) Due to the fact conversion patterns (date atleast) can be dynamic (user preference for date formatting, etc.), I would imagine the taglibs would still have to have the opportunity to override the static XML default definition. I think expanding the Converter interface to accept "configuration" parameters would allow for a more robust ConvertUtils. Unfortunately, to get to the conversion (from Struts), you have to get through the BeanUtils.populate method and I do not know if it's at this point this "Field Descriptor" object comes into play. I do like the relative simplicity of the current method. Prior to Struts existence (almost unimaginable!) myself and another developer built a MVC implementation for webapps that had just such an object and the ActionForm was merely an container for related "ActionField"s. This had it's problems as it oversimplified the relationship between fields...perhaps a hybrid is instore? I appreciate centralizing properties, but I think some of the properties you mentioned (i.e. style, title/titleKey, etc.) are not really in the buffer space, but solidly fixed in the html/jsp space. I think it is probably a violation of the separation of concerns to define such UI specific elements outside of the space they come from. I do like the idea of combining the validation definition with target datatype/conversion mechanism to simplify the work of defining a UI field. Perhaps the Struts schema could wrap (and expand upon) the elements in the validation dtd allowing for a single point of entry for field definitions? --- Ted Husted <joseph67@example.org> wrote: > Fixing ConvertUtils would seem like a better > solution to me than making > this many workarounds to support a single data type. > > If we make these kind of patches to Struts, we've > only "helped" Struts. > If we fix ConvertUtils, we can help any other > application or framework > that uses ConvertUtils. > > I believe the consensus has been that the ActionForm > should represent > Strings as they are entered into the HTML form. Once > the Strings pass > validation, then data conversion should occur as the > data moves toward > the business and system tiers. > > I would agree that the ActionForm oversimplifies the > problem. There is > definitely a need for a object that incorporates > many more attributes > into a single configuration, target datatype being > one of these. But, > IMHO, offering up a patch for just the Date datatype > would be a step in > the wrong direction. > > We've come to say that the ActionForm is the missing > buffer for the HTML > controls. I would suggest that we should take that > to heart and make it > an actual buffer object for data-entry controls. > We've already started > to add a second layer of description to the > ActionForm in the guise of > the Validator forms. We've also started to define > the ActionForm itself > in XML under the auspice of DynaValidatorForm. > Perhaps we should put > both of these things together and define a true > field and form buffer > object that can be define in XML. > > Aside from target datatype, the Field/Form > descriptor could also have > places to define the label, displaysize, maxlength, > control, readonly, > disabled, tabindex, required, validator, default, > alt, altKey, style, > styleClass, styleId, title, titleKey, and Java on* > events. > > We already enter all of these things into the > application someplace, and > it would be helpful if they could all be gathered > together where they > could be reused. > > The object would be an excellent place to put more > advanced data > conversion routines, such as those required for > dates. It could also be > used by other applications and frameworks outside of > Struts. > > -Ted. > > Jon Wilmoth wrote: > > As I've found with my involvement in contributing > to > > the Bugzilla project, radification/confirmation of > > design/implementation details is critical to > > acceptance of a submitted patch. Below are the > > changes I propose to make this happen. The String > --> > > Date direction is significanly more involved than > > rendering the date as a String. I investigated > > performing the conversion in ConvertUtils for > both, > > but without overloading the Converter.convert > > interface to accept a map of conversion parameters > > made available to the registered Converter > > implementations this is not possible. Further > more, > > the BeanUtils.populate method signature would also > > need to change to accomodate a collection of > property > > specific conversion parameter name/value pairs to > use > > this new convert method. Thus what's outlined > below > > involves changes in the Struts code base only! > > > > String --> Date > > 1) Add "dateformat" attribute to all html input > tags. > > This would specify the java.text.SimpleDateFormat > > pattern of the string being submitted. Tag would > > generate hidden field and a > PropertyConversionParam > > (new class) instance stored under the user's > session > > with PropertyConversionParam.getKey() used as the > > session attribute and the hidden field name. This > > would only be performed by the tag if the bean's > > property type was a date AND 'dateformat' > attribute > > was specified. > > > > Scratchpad of PropertyConversionParam class: > > > > PropertyConversionParam { > > > > public static final String KEY_PREFIX = > > "conversion-param"; > > public static final String > DATE_CONVERSION_PATTERN = > > "dateConversionPattern"; > > > > //simple setter/getter properties > > private String beanName; > > private String property; > > private String paramName; > > private String conversionValue; > > > > //calculated namespace key > > private String key = null; > > > > public String getKey() { > > if (key == null) { > > key = KEY_PREFIX + > > String.valueOf(beanName.hashCode()) + > > String.valueOf(property.hashCode()) + > > String.valueOf(paramName.hashCode()); > > } > > return key; > > } > > } > > > > 2) Modify RequestUtils.populate: > > * For each property that has a dateformat value > > present remove Session PropertyConversionParam > > attribute and do not store name/value pair in map > > given to BeanUtils.populate method. > > * If there is a null attribute value ignore and > allow > > existing Converters to attempt conversion. > > > > 3) Add new DateUtil class to struts util package > with > > methods: > > - java.util.Date toDate(String pattern, String > value) > > - String toString(String pattern, java.util.Date > > value) > > Realizing the tidyness of centralizing the > conversion > > behaviour, these methods could simply be added to > the > > ConvertUtils. > > > > 4) Modify RequestProcessor.processPopulate > > (processPopulateConversions ?): > > * After call to RequestUtils.populate() remove > > session attributes that begin with > > PropertyConversionParam.KEY_PREFIX > > * For each PropertyConversionParam that has a > > non-null request parameter conversion value, call > > BeanUtils.setProperty(Object, String, Object) > after > > convert the string date to date a java.util.Date > using > > DateUtil.toDate. > > PropertyConversionParam.getConversionValue() would > > provide 'pattern' parameter while request would > > provide the 'value' parameter. > > * For each string --> date conversion that fails > add > > a ActionError instance for the property and follow > > same redirect logic detailed in processValidate > method > > (perhaps a method extract refactoring). > > > > > > Date --> String > > 1) add "dateformat" attribute to bean:write tag & > all > > html input tags > > 2) modify tag to call DateUtil.toString if bean > > property is of type Date and "dateformat" > attribute is > > not null > > > > Please realize this is a first cut and I expect to > > incorporate loads of feedback prior to submitting > a > > patch. > > > > --- Joe Germuska <joseph67@example.org> wrote: > > > >>At 11:23 -0700 6/27/03, Jon Wilmoth wrote: > >> > >>>I'm reposting as the previous attempt may have > >> > >>gotten > >> > >>>lost in the new release excitement. > >>> > >>>I'd like to know what the CURRENT plans are for > >>>supporting date datatypes in the framework. This > >>>means conversion of strings --> dates for > FormBean > >>>population and the converse date --> string for > >>>rendering FormBean values. > >> > >>I think submitting a patch would be the most > >>effective way to get > >>this put into plans. But note that the > >>string-to-object conversion > >>is generally handled in Commons BeanUtils, not > >>directly in Struts. > >>The Struts "problem" to solve is where to specify > >>the date format > >>conversion, and unless you want to support only > one > >>date format for a > >>whole application, how to pass date formats along > to > >>the form > >>population process at the right time. > >> > >>How do you propose to handle the variety of > possible > >>date formats? > >>Between the fact that that's a mildly complicated > >>question and the > >>fact that at least some Struts developers think > that > >>you should just > >>use String types for all text fields in your > forms, > >>I suspect that's > >>why you haven't seen any "official" support. > >> > >>But if you submit a patch or at least start a > >>discussion of the > >>implementation issues, I'm sure you'll get > opinions. > >> There are lots > >>of those around here ;-) > >> > >>Joe > >> > >>-- > >>-- > >>Joe Germuska > >>joseph67@example.org > >>http://blog.germuska.com > >>"If nature worked that way, the universe would > crash > >>all the time." > >> --Jaron Lanier > >> > >> > > > > > --------------------------------------------------------------------- > > > >>To unsubscribe, e-mail: > >>joseph67@example.org > >>For additional commands, e-mail: > >>joseph67@example.org > >> > > > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > joseph67@example.org > > For additional commands, e-mail: > joseph67@example.org > > > > > > > -- > Ted Husted, > Struts in Action > <http://husted.com/struts/book.html> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > joseph67@example.org > For additional commands, e-mail: > joseph67@example.org > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:21:37 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 71330 invoked from network); 1 Jul 2003 17:21:36 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:21:36 -0000 Received: (qmail 20191 invoked by uid 97); 1 Jul 2003 17:24:03 -0000 Delivered-To: joseph67@example.org Received: (qmail 20183 invoked from network); 1 Jul 2003 17:24:03 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:24:03 -0000 Received: (qmail 70605 invoked by uid 500); 1 Jul 2003 17:21:28 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 70588 invoked from network); 1 Jul 2003 17:21:28 -0000 Received: from web20710.mail.yahoo.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:21:28 -0000 Message-ID: <joseph67@example.org> Received: from [83.161.120.155] by web20710.mail.yahoo.com via HTTP; Tue, 01 Jul 2003 10:21:32 PDT Date: Tue, 1 Jul 2003 10:21:32 -0700 (PDT) From: David Graham <joseph67@example.org> Reply-To: joseph67@example.org Subject: Re: Support for Date datatypes!!! To: Struts Developers List <joseph67@example.org> In-Reply-To: <joseph67@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I appreciate centralizing properties, but I think some > of the properties you mentioned (i.e. style, > title/titleKey, etc.) are not really in the buffer > space, but solidly fixed in the html/jsp space. I > think it is probably a violation of the separation of > concerns to define such UI specific elements outside > of the space they come from. I do like the idea of > combining the validation definition with target > datatype/conversion mechanism to simplify the work of > defining a UI field. Perhaps the Struts schema could > wrap (and expand upon) the elements in the validation > dtd allowing for a single point of entry for field > definitions? Once you combine struts-config.xml with validation.xml you lose the ability to leverage commons-validator's ability to parse validation.xml and configure itself. Struts would have to setup commons-validator itself which isn't rocket science but it's probably not trivial either. David > > --- Ted Husted <joseph67@example.org> wrote: > > Fixing ConvertUtils would seem like a better > > solution to me than making > > this many workarounds to support a single data type. > > > > If we make these kind of patches to Struts, we've > > only "helped" Struts. > > If we fix ConvertUtils, we can help any other > > application or framework > > that uses ConvertUtils. > > > > I believe the consensus has been that the ActionForm > > should represent > > Strings as they are entered into the HTML form. Once > > the Strings pass > > validation, then data conversion should occur as the > > data moves toward > > the business and system tiers. > > > > I would agree that the ActionForm oversimplifies the > > problem. There is > > definitely a need for a object that incorporates > > many more attributes > > into a single configuration, target datatype being > > one of these. But, > > IMHO, offering up a patch for just the Date datatype > > would be a step in > > the wrong direction. > > > > We've come to say that the ActionForm is the missing > > buffer for the HTML > > controls. I would suggest that we should take that > > to heart and make it > > an actual buffer object for data-entry controls. > > We've already started > > to add a second layer of description to the > > ActionForm in the guise of > > the Validator forms. We've also started to define > > the ActionForm itself > > in XML under the auspice of DynaValidatorForm. > > Perhaps we should put > > both of these things together and define a true > > field and form buffer > > object that can be define in XML. > > > > Aside from target datatype, the Field/Form > > descriptor could also have > > places to define the label, displaysize, maxlength, > > control, readonly, > > disabled, tabindex, required, validator, default, > > alt, altKey, style, > > styleClass, styleId, title, titleKey, and Java on* > > events. > > > > We already enter all of these things into the > > application someplace, and > > it would be helpful if they could all be gathered > > together where they > > could be reused. > > > > The object would be an excellent place to put more > > advanced data > > conversion routines, such as those required for > > dates. It could also be > > used by other applications and frameworks outside of > > Struts. > > > > -Ted. > > > > Jon Wilmoth wrote: > > > As I've found with my involvement in contributing > > to > > > the Bugzilla project, radification/confirmation of > > > design/implementation details is critical to > > > acceptance of a submitted patch. Below are the > > > changes I propose to make this happen. The String > > --> > > > Date direction is significanly more involved than > > > rendering the date as a String. I investigated > > > performing the conversion in ConvertUtils for > > both, > > > but without overloading the Converter.convert > > > interface to accept a map of conversion parameters > > > made available to the registered Converter > > > implementations this is not possible. Further > > more, > > > the BeanUtils.populate method signature would also > > > need to change to accomodate a collection of > > property > > > specific conversion parameter name/value pairs to > > use > > > this new convert method. Thus what's outlined > > below > > > involves changes in the Struts code base only! > > > > > > String --> Date > > > 1) Add "dateformat" attribute to all html input > > tags. > > > This would specify the java.text.SimpleDateFormat > > > pattern of the string being submitted. Tag would > > > generate hidden field and a > > PropertyConversionParam > > > (new class) instance stored under the user's > > session > > > with PropertyConversionParam.getKey() used as the > > > session attribute and the hidden field name. This > > > would only be performed by the tag if the bean's > > > property type was a date AND 'dateformat' > > attribute > > > was specified. > > > > > > Scratchpad of PropertyConversionParam class: > > > > > > PropertyConversionParam { > > > > > > public static final String KEY_PREFIX = > > > "conversion-param"; > > > public static final String > > DATE_CONVERSION_PATTERN = > > > "dateConversionPattern"; > > > > > > //simple setter/getter properties > > > private String beanName; > > > private String property; > > > private String paramName; > > > private String conversionValue; > > > > > > //calculated namespace key > > > private String key = null; > > > > > > public String getKey() { > > > if (key == null) { > > > key = KEY_PREFIX + > > > String.valueOf(beanName.hashCode()) + > > > String.valueOf(property.hashCode()) + > > > String.valueOf(paramName.hashCode()); > > > } > > > return key; > > > } > > > } > > > > > > 2) Modify RequestUtils.populate: > > > * For each property that has a dateformat value > > > present remove Session PropertyConversionParam > > > attribute and do not store name/value pair in map > > > given to BeanUtils.populate method. > > > * If there is a null attribute value ignore and > === message truncated === __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:31:19 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 84158 invoked from network); 1 Jul 2003 17:31:18 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:31:18 -0000 Received: (qmail 20509 invoked by uid 97); 1 Jul 2003 17:33:45 -0000 Delivered-To: joseph67@example.org Received: (qmail 20502 invoked from network); 1 Jul 2003 17:33:44 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:33:44 -0000 Received: (qmail 83520 invoked by uid 500); 1 Jul 2003 17:31:11 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 83509 invoked from network); 1 Jul 2003 17:31:11 -0000 Received: from post2.inre.asu.edu (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:31:11 -0000 Received: from conversion.post2.inre.asu.edu by asu.edu (PMDF V6.1 #40111) id <joseph67@example.org> for joseph67@example.org; Tue, 01 Jul 2003 10:30:45 -0700 (MST) Received: from mainexzz.asu.edu (mainexzz.asu.edu [83.161.120.155]) by asu.edu (PMDF V6.1 #40111) with ESMTP id <joseph67@example.org> for joseph67@example.org; Tue, 01 Jul 2003 10:30:44 -0700 (MST) Received: by mainexzz.asu.edu with Internet Mail Service (5.5.2653.19) id <M125XDL8>; Tue, 01 Jul 2003 10:30:45 -0700 Content-return: allowed Date: Tue, 01 Jul 2003 10:30:40 -0700 From: Wendy Smoak <joseph67@example.org> Subject: RE: Support for Date datatypes!!! To: 'Struts Developers List' <joseph67@example.org> Message-id: <joseph67@example.org> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_f9FxIjhx8LBojDrx/ffYag)" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --Boundary_(ID_f9FxIjhx8LBojDrx/ffYag) Content-type: text/plain [Not a developer, but I've been following this because I ran into the date problem early on.] I use BeanUtils.copyProperties to move things back and forth from ActionForms (all String properties) and my DTO's, as shown in the struts-example webapp. At some point I thought needed a Java "Date" object in the DTO (that requirement went away with further development). And the existing SQL formatted Date converter wasn't going to work, my database doesn't understand that format. What was suggested to me is writing and registering my own Converter with BeanUtils. I don't think I went through with it, but that made perfect sense to me. IMO, Struts shouldn't get involved with Date conversions, that's already the job of Commons BeanUtils. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM --Boundary_(ID_f9FxIjhx8LBojDrx/ffYag)-- From struts-dev-joseph67@example.org Tue Jul 01 17:45:49 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 6860 invoked from network); 1 Jul 2003 17:45:49 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:45:49 -0000 Received: (qmail 20928 invoked by uid 97); 1 Jul 2003 17:48:15 -0000 Delivered-To: joseph67@example.org Received: (qmail 20921 invoked from network); 1 Jul 2003 17:48:15 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:48:15 -0000 Received: (qmail 5996 invoked by uid 500); 1 Jul 2003 17:45:40 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 5983 invoked from network); 1 Jul 2003 17:45:40 -0000 Received: from web11501.mail.yahoo.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:45:40 -0000 Message-ID: <joseph67@example.org> Received: from [83.161.120.155] by web11501.mail.yahoo.com via HTTP; Tue, 01 Jul 2003 10:45:44 PDT Date: Tue, 1 Jul 2003 10:45:44 -0700 (PDT) From: Jon Wilmoth <joseph67@example.org> Reply-To: joseph67@example.org Subject: [BeanUtils & Struts]RE: Support for Date datatypes!!! To: Struts Developers List <joseph67@example.org> In-Reply-To: <joseph67@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I did investigate registering "custom" converters. Unfortunately, anything that would support non-hard-coded conversion patterns will require either a mixed paradygm usage (i.e passing a complex object that contains the value to convert and all convertion configuration instead of simply the value to be converted) of the existing Converter.convert interface or additional parameters. Since I think everyone can agree that the first option is confusing and should be avoided when possible the remaining option is to modify/extend the interface. I agree this should be communicated within the BeanUtils developer mailing list and will cross post this in hopes of getting further creative approaches to the problem. Because Struts will be responsible for providing the means to invoke the conversion (and much more) I do feel it is appropriate for this list to continue to discuss the Struts/BeanUtil interaction necessary for this functionality. --- Wendy Smoak <joseph67@example.org> wrote: > > [Not a developer, but I've been following this > because I ran into the date > problem early on.] I use BeanUtils.copyProperties > to move things back and > forth from ActionForms (all String properties) and > my DTO's, as shown in the > struts-example webapp. At some point I thought > needed a Java "Date" object > in the DTO (that requirement went away with further > development). And the > existing SQL formatted Date converter wasn't going > to work, my database > doesn't understand that format. > > What was suggested to me is writing and registering > my own Converter with > BeanUtils. I don't think I went through with it, > but that made perfect > sense to me. IMO, Struts shouldn't get involved > with Date conversions, > that's already the job of Commons BeanUtils. > > -- > Wendy Smoak > Applications Systems Analyst, Sr. > Arizona State University, PA, IRM > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:49:34 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 12036 invoked from network); 1 Jul 2003 17:49:33 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:49:33 -0000 Received: (qmail 21002 invoked by uid 97); 1 Jul 2003 17:52:00 -0000 Delivered-To: joseph67@example.org Received: (qmail 20994 invoked from network); 1 Jul 2003 17:52:00 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:52:00 -0000 Received: (qmail 11443 invoked by uid 500); 1 Jul 2003 17:49:27 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 11428 invoked by uid 500); 1 Jul 2003 17:49:27 -0000 Received: (qmail 11422 invoked from network); 1 Jul 2003 17:49:27 -0000 Received: from icarus.apache.org (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:49:27 -0000 Received: (qmail 37093 invoked by uid 1573); 1 Jul 2003 17:49:26 -0000 Date: 1 Jul 2003 17:49:26 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/validator/validwhen ValidWhen.java ValidWhenLexer.java ValidWhenParser.g ValidWhenParser.java ValidWhenParserTokenTypes.java ValidWhenParserTokenTypes.txt X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N turner 2003/07/01 10:49:26 Modified: . build.properties.sample build.xml Added: src/share/org/apache/struts/validator/validwhen ValidWhen.java ValidWhenLexer.java ValidWhenParser.g ValidWhenParser.java ValidWhenParserTokenTypes.java ValidWhenParserTokenTypes.txt Log: Re-add validwhen validation removed for the 1.1 release. NOTE: The nightly build machine is going to need to be updated to have the required ANTLR support library James Revision Changes Path 1.43 +7 -1 jakarta-struts/build.properties.sample Index: build.properties.sample =================================================================== RCS file: /home/cvs/jakarta-struts/build.properties.sample,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- build.properties.sample 29 Jun 2003 05:27:58 -0000 1.42 +++ build.properties.sample 1 Jul 2003 17:49:25 -0000 1.43 @@ -98,6 +98,12 @@ # going to execute the "deploy.catalina" target. xerces.jar=${apache.home}/xerces-1_4_4/xerces.jar +# The JAR file containing the ANTLR runtime support classes, needed for the +# validwhen validator rule to work. You can get this file from: +# http://www.antlr.org/ +antlr.jar = ../../..//antlr-2.7.1/antlr.jar + + # Properties related to optional tasks # ------------------------------------ 1.112 +7 -0 jakarta-struts/build.xml Index: build.xml =================================================================== RCS file: /home/cvs/jakarta-struts/build.xml,v retrieving revision 1.111 retrieving revision 1.112 diff -u -r1.111 -r1.112 --- build.xml 29 Jun 2003 05:25:32 -0000 1.111 +++ build.xml 1 Jul 2003 17:49:25 -0000 1.112 @@ -82,6 +82,10 @@ classes to compile against (currently, either version 2.2 or 2.3 supported). + antlr.jar (required) The path to the ANTLR classes + to copy. Required for the validwhen + validator rule to parser it's args. + tomcat.home (optional). The path to the Tomcat 3.x installation. This is required only when executing the "deploy.tomcat" target. @@ -204,6 +208,7 @@ <pathelement location="${jdbc20ext.jar}"/> <pathelement location="${jsp.jar}"/> <pathelement location="${servlet.jar}"/> + <pathelement location="${antlr.jar}"/> <pathelement location="${xerces.jar}"/> </path> @@ -261,6 +266,8 @@ tofile="${build.home}/library/commons-validator.jar"/> <copy file="${jakarta-oro.jar}" tofile="${build.home}/library/jakarta-oro.jar"/> + <copy file="${antlr.jar}" failonerror="false" + tofile="${build.home}/library/antlr.jar"/> <!-- Compile-time dependency only <copy file="${jdbc20ext.jar}" tofile="${build.home}/library/jdbc2_0-stdext.jar"/> 1.4 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhen.java 1.3 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhenLexer.java 1.3 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhenParser.g 1.5 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhenParser.java 1.3 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhenParserTokenTypes.java 1.3 +0 -0 jakarta-struts/src/share/org/apache/struts/validator/validwhen/ValidWhenParserTokenTypes.txt --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:52:17 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 15946 invoked from network); 1 Jul 2003 17:52:16 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:52:16 -0000 Received: (qmail 21062 invoked by uid 97); 1 Jul 2003 17:54:43 -0000 Delivered-To: joseph67@example.org Received: (qmail 21055 invoked from network); 1 Jul 2003 17:54:43 -0000 Received: from daedalus.apache.org (HELO apache.org) (83.161.120.155) by nagoya.betaversion.org with SMTP; 1 Jul 2003 17:54:43 -0000 Received: (qmail 15355 invoked by uid 500); 1 Jul 2003 17:52:11 -0000 Mailing-List: contact joseph67@example.org; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:joseph67@example.org> List-Subscribe: <mailto:joseph67@example.org> List-Help: <mailto:joseph67@example.org> List-Post: <mailto:joseph67@example.org> List-Id: "Struts Developers List" <struts-dev.jakarta.apache.org> Reply-To: "Struts Developers List" <joseph67@example.org> Delivered-To: mailing list joseph67@example.org Received: (qmail 15344 invoked by uid 500); 1 Jul 2003 17:52:10 -0000 Received: (qmail 15341 invoked from network); 1 Jul 2003 17:52:10 -0000 Received: from icarus.apache.org (83.161.120.155) by daedalus.apache.org with SMTP; 1 Jul 2003 17:52:10 -0000 Received: (qmail 38118 invoked by uid 1573); 1 Jul 2003 17:52:10 -0000 Date: 1 Jul 2003 17:52:10 -0000 Message-ID: <joseph67@example.org> From: joseph67@example.org To: joseph67@example.org Subject: cvs commit: jakarta-struts/conf/share validator-rules.xml X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N turner 2003/07/01 10:52:10 Modified: conf/share validator-rules.xml Log: Add validwhen validation Revision Changes Path 1.34 +12 -0 jakarta-struts/conf/share/validator-rules.xml Index: validator-rules.xml =================================================================== RCS file: /home/cvs/jakarta-struts/conf/share/validator-rules.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- validator-rules.xml 25 Jun 2003 02:10:35 -0000 1.33 +++ validator-rules.xml 1 Jul 2003 17:52:09 -0000 1.34 @@ -120,6 +120,18 @@ msg="errors.required"> </validator> + <validator name="validwhen" + msg="errors.required" + classname="org.apache.struts.validator.validwhen.ValidWhen" + method="validateValidWhen" + methodParams="java.lang.Object, + org.apache.commons.validator.ValidatorAction, + org.apache.commons.validator.Field, + org.apache.struts.action.ActionErrors, + org.apache.commons.validator.Validator, + javax.servlet.http.HttpServletRequest"/> + + <validator name="minlength" classname="org.apache.struts.validator.FieldChecks" method="validateMinLength" --------------------------------------------------------------------- To unsubscribe, e-mail: joseph67@example.org For additional commands, e-mail: joseph67@example.org From struts-dev-joseph67@example.org Tue Jul 01 17:54:38 2003 Return-Path: <struts-dev-joseph67@example.org> Delivered-To: joseph67@example.org Received: (qmail 20887 invoked from network); 1 Jul 2003 17:54:37 -0000 Received: from
{'source': 'Apache Software Foundation Public Mail Archives'}