DO NOT REPLY [Bug 15196] - Bug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the parameter
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=15196. 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=15196 Bug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the parameter [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-12-26 15:23 --- Why computeParameter (or other base classes of html tags) did not explicity check for bean that implements org.apache.commons.beanutils.DynaBean, for example with an istanceOf istruction? Another useful functionality may be to provide a method attribute on html tags, used when property attribute is not usable. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15670] New: - Doc for exception element needs to mention page and exception in req. scope
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=15670. 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=15670 Doc for exception element needs to mention page and exception in req. scope Summary: Doc for exception element needs to mention page and exception in req. scope Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation in (currently) section 4.5, titled Exception Handler, could use more details about the optional attributes of the exception element, like the page attribute, which isn't mentioned here. In addition, it should mention that the default exception handler (if you don't specify a type attribute) puts the found exception into request scope under the Globals.EXCEPTION_KEY key. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15670] - Doc for exception element needs to mention page and exception in req. scope
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=15670. 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=15670 Doc for exception element needs to mention page and exception in req. scope --- Additional Comments From [EMAIL PROTECTED] 2002-12-26 16:48 --- If it matters, in my comment, the mention of the type attribute should have been the handler attribute. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
On Wed, 25 Dec 2002, Ted Husted wrote: 12/24/2002 6:53:29 PM, Martin Cooper [EMAIL PROTECTED] wrote: The plan doesn't say we're committing to fixing the problem, it says the problem report must be resolved before final release of Struts 1.1. I believe we need to do that, even if we have to mark it LATER because we haven't been able to reproduce it or track it down by the time we're otherwise ready for a final release. Since we already say that under Release Criteria, I'd suggest we drop the Bugs to be Addressed section as redundant and replace the link to Bugzilla with one that will produce the list we need to address. There are a couple of reasons I'm reluctant to do that. * The bug list was added at Craig's suggestion on the vote for the 1.1-b1 release plan. It's based on previous experience with Tomcat releases. See: http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgNo=7086 * I believe we need a somewhat fixed target to aim at, rather than a moving one. If we use a link to Bugzilla rather than a list that we agree upon, then it would presumably mean that if someone submits a new bug report at 23:55 on the proposed release date, we are no longer ready for the release, since the link in the release plan now refers to a non-empty list of bugs that need to be resolved before the release can happen. The use of the STATUS file that Craig introduced before might be a good compromise between using the list in the release plan and using a link to Bugzilla. This file would get updated as bugs get fixed, and if someone believes a new bug also needs to be fixed before release, they can add it to the file. That commit would, as always, be subject to veto if someone else disagrees, thus using the usual code voting mechanism to control the list. -- Martin Cooper Apparently, this is the Bugzilla link on the Roadmap, less the enhancement requests. (Edit the query and select everything but.) http://issues.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_stat us=REOPENEDbug_severity=Blockerbug_severity=Criticalbug_severit y=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1 =substringemailassigned_to1=1email2=emailtype2 =substringemailreporter2=1 bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldt o=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=all wordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc= bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywords field0-0-0=nooptype0-0-0=noopvalue0-0-0 =cmdtype=doitnewqueryname=order=%27Importance%27 -T. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
Craig's message mentions an up to the minute list, which I believe should be a Bugzilla query. If something comes in just before the freeze, and it's not a true show stopper, we can just make it LATER, which we should be doing anyway. I would just like to get out of the habit of dual maintenance of multiple lists. -Ted. 12/26/2002 3:40:43 PM, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 25 Dec 2002, Ted Husted wrote: 12/24/2002 6:53:29 PM, Martin Cooper [EMAIL PROTECTED] wrote: The plan doesn't say we're committing to fixing the problem, it says the problem report must be resolved before final release of Struts 1.1. I believe we need to do that, even if we have to mark it LATER because we haven't been able to reproduce it or track it down by the time we're otherwise ready for a final release. Since we already say that under Release Criteria, I'd suggest we drop the Bugs to be Addressed section as redundant and replace the link to Bugzilla with one that will produce the list we need to address. There are a couple of reasons I'm reluctant to do that. * The bug list was added at Craig's suggestion on the vote for the 1.1-b1 release plan. It's based on previous experience with Tomcat releases. See: http://archives.apache.org/eyebrowse/ReadMsg?listName=struts- [EMAIL PROTECTED]msgNo=7086 * I believe we need a somewhat fixed target to aim at, rather than a moving one. If we use a link to Bugzilla rather than a list that we agree upon, then it would presumably mean that if someone submits a new bug report at 23:55 on the proposed release date, we are no longer ready for the release, since the link in the release plan now refers to a non-empty list of bugs that need to be resolved before the release can happen. The use of the STATUS file that Craig introduced before might be a good compromise between using the list in the release plan and using a link to Bugzilla. This file would get updated as bugs get fixed, and if someone believes a new bug also needs to be fixed before release, they can add it to the file. That commit would, as always, be subject to veto if someone else disagrees, thus using the usual code voting mechanism to control the list. -- Martin Cooper Apparently, this is the Bugzilla link on the Roadmap, less the enhancement requests. (Edit the query and select everything but.) http://issues.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_stat us=REOPENEDbug_severity=Blockerbug_severity=Criticalbug_severit y=Majorbug_severity=Normalbug_severity=Minoremail1 =emailtype1 =substringemailassigned_to1=1email2=emailtype2 =substringemailreporter2=1 bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldt o=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=all wordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc= bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywords field0-0-0=nooptype0-0-0=noopvalue0-0-0 =cmdtype=doitnewqueryname=order=%27Importance%27 -T. -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
On Thu, 26 Dec 2002, Ted Husted wrote: Date: Thu, 26 Dec 2002 16:55:34 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised) Craig's message mentions an up to the minute list, which I believe should be a Bugzilla query. I think this is definitely a useful query to have available, but I'm somewhat agreeing with Martin that a dynamic query doesn't really represent an agreed-upon target for a beta release (1.1) or a milestone release (1.2+). I believe that it is useful to have some measure of agreement on which subset of the current Bugzilla entries must be handled. Leaving the list dynamic means that it will essentially never be completed, and that a release will keep getting deferred until a few more bugs get addressed - which sounds suspiciously like one of the things that has delayed beta 3 :-). If something comes in just before the freeze, and it's not a true show stopper, we can just make it LATER, which we should be doing anyway. If we want to get more aggressive about using LATER, the Target Milestone field in Bugzilla is available for identifying *which* future release we think a particular bug report will be resolved in. This will be particularly useful in planning work for 1.2.x releases (which shouldn't necessarily need to be complete clean sweeps of all the outstanding bugs, if we follow the model used for the HTTPD server and Tomcat). I would just like to get out of the habit of dual maintenance of multiple lists. -Ted. Craig PS: I'm looking at the convert to commons-resources issue that we've talked about, but not yet done. Among other things, this needs to be done (if we're going to) before dealing with 11932. I'm also planning on dealing with that one. 12/26/2002 3:40:43 PM, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 25 Dec 2002, Ted Husted wrote: 12/24/2002 6:53:29 PM, Martin Cooper [EMAIL PROTECTED] wrote: The plan doesn't say we're committing to fixing the problem, it says the problem report must be resolved before final release of Struts 1.1. I believe we need to do that, even if we have to mark it LATER because we haven't been able to reproduce it or track it down by the time we're otherwise ready for a final release. Since we already say that under Release Criteria, I'd suggest we drop the Bugs to be Addressed section as redundant and replace the link to Bugzilla with one that will produce the list we need to address. There are a couple of reasons I'm reluctant to do that. * The bug list was added at Craig's suggestion on the vote for the 1.1-b1 release plan. It's based on previous experience with Tomcat releases. See: http://archives.apache.org/eyebrowse/ReadMsg?listName=struts- [EMAIL PROTECTED]msgNo=7086 * I believe we need a somewhat fixed target to aim at, rather than a moving one. If we use a link to Bugzilla rather than a list that we agree upon, then it would presumably mean that if someone submits a new bug report at 23:55 on the proposed release date, we are no longer ready for the release, since the link in the release plan now refers to a non-empty list of bugs that need to be resolved before the release can happen. The use of the STATUS file that Craig introduced before might be a good compromise between using the list in the release plan and using a link to Bugzilla. This file would get updated as bugs get fixed, and if someone believes a new bug also needs to be fixed before release, they can add it to the file. That commit would, as always, be subject to veto if someone else disagrees, thus using the usual code voting mechanism to control the list. -- Martin Cooper Apparently, this is the Bugzilla link on the Roadmap, less the enhancement requests. (Edit the query and select everything but.) http://issues.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_stat us=REOPENEDbug_severity=Blockerbug_severity=Criticalbug_severit y=Majorbug_severity=Normalbug_severity=Minoremail1 =emailtype1 =substringemailassigned_to1=1email2=emailtype2 =substringemailreporter2=1 bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldt o=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=all wordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc= bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywords field0-0-0=nooptype0-0-0=noopvalue0-0-0 =cmdtype=doitnewqueryname=order=%27Importance%27 -T. -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe,
DO NOT REPLY [Bug 15673] New: - Default Action in 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=15673. 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=15673 Default Action in ActionMapping Summary: Default Action in ActionMapping Product: Struts Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be nice to have a default forward in the action mappings. This would allow multiple page forms to work with a single action class in a more elegant way. Currently, the work around is the input page. If you would like this implemented, I would be more than happy to. Edgar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
Ok, I'll update the Roadmap and the B3 plan with the appropriate queries, and add a box next to the bugs we are swatting to indicate their status. This will at least make the static list easier to maintain =:0) Just finished setting a bunch of new equipment, and I'm quite ready to get back to work now =:0) -Ted. Craig R. McClanahan wrote: On Thu, 26 Dec 2002, Ted Husted wrote: Date: Thu, 26 Dec 2002 16:55:34 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised) Craig's message mentions an up to the minute list, which I believe should be a Bugzilla query. I think this is definitely a useful query to have available, but I'm somewhat agreeing with Martin that a dynamic query doesn't really represent an agreed-upon target for a beta release (1.1) or a milestone release (1.2+). I believe that it is useful to have some measure of agreement on which subset of the current Bugzilla entries must be handled. Leaving the list dynamic means that it will essentially never be completed, and that a release will keep getting deferred until a few more bugs get addressed - which sounds suspiciously like one of the things that has delayed beta 3 :-). If something comes in just before the freeze, and it's not a true show stopper, we can just make it LATER, which we should be doing anyway. If we want to get more aggressive about using LATER, the Target Milestone field in Bugzilla is available for identifying *which* future release we think a particular bug report will be resolved in. This will be particularly useful in planning work for 1.2.x releases (which shouldn't necessarily need to be complete clean sweeps of all the outstanding bugs, if we follow the model used for the HTTPD server and Tomcat). I would just like to get out of the habit of dual maintenance of multiple lists. -Ted. Craig PS: I'm looking at the convert to commons-resources issue that we've talked about, but not yet done. Among other things, this needs to be done (if we're going to) before dealing with 11932. I'm also planning on dealing with that one. 12/26/2002 3:40:43 PM, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 25 Dec 2002, Ted Husted wrote: 12/24/2002 6:53:29 PM, Martin Cooper [EMAIL PROTECTED] wrote: The plan doesn't say we're committing to fixing the problem, it says the problem report must be resolved before final release of Struts 1.1. I believe we need to do that, even if we have to mark it LATER because we haven't been able to reproduce it or track it down by the time we're otherwise ready for a final release. Since we already say that under Release Criteria, I'd suggest we drop the Bugs to be Addressed section as redundant and replace the link to Bugzilla with one that will produce the list we need to address. There are a couple of reasons I'm reluctant to do that. * The bug list was added at Craig's suggestion on the vote for the 1.1-b1 release plan. It's based on previous experience with Tomcat releases. See: http://archives.apache.org/eyebrowse/ReadMsg?listName=struts- [EMAIL PROTECTED]msgNo=7086 * I believe we need a somewhat fixed target to aim at, rather than a moving one. If we use a link to Bugzilla rather than a list that we agree upon, then it would presumably mean that if someone submits a new bug report at 23:55 on the proposed release date, we are no longer ready for the release, since the link in the release plan now refers to a non-empty list of bugs that need to be resolved before the release can happen. The use of the STATUS file that Craig introduced before might be a good compromise between using the list in the release plan and using a link to Bugzilla. This file would get updated as bugs get fixed, and if someone believes a new bug also needs to be fixed before release, they can add it to the file. That commit would, as always, be subject to veto if someone else disagrees, thus using the usual code voting mechanism to control the list. -- Martin Cooper Apparently, this is the Bugzilla link on the Roadmap, less the enhancement requests. (Edit the query and select everything but.) http://issues.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_stat us=REOPENEDbug_severity=Blockerbug_severity=Criticalbug_severit y=Majorbug_severity=Normalbug_severity=Minoremail1 =emailtype1 =substringemailassigned_to1=1email2=emailtype2 =substringemailreporter2=1 bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldt o=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=all wordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc= bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywords field0-0-0=nooptype0-0-0=noopvalue0-0-0
DO NOT REPLY [Bug 15673] - Default Action in 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=15673. 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=15673 Default Action in ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2002-12-26 23:31 --- Could you elaborate on what you mean by this? I set up a global success forward that simply goes to the home page of our site and generally speaking all successful actions forward to the success mapping. If an action mapping doesn't have a success mapping then it uses the global one. To me this sounds like what you're are asking for, so I'm looking for clarification. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15673] - Default Action in 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=15673. 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=15673 Default Action in ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2002-12-26 23:49 --- The global success doesn't really work for me since I prefer to leave the data on the screen that resulted in a success. I am using the ValidationErrors to return 'success' to the page which satisfies that need. Also, I am using the controller for smaller actions which don't necessarily result in a 'success'. Suppose you have a 'customer entry' series of screens surrounding a fairly complex form. Also suppose you would like to write generic action classes for complex forms. Also assume that the action class is decomposing standard form data to determine the action to perform (there are dozens of potential actions). The first requirement is an extension of ActionForm which has all the 'standard' actions and also maintains action state. You start the action sequence with a populate action to fill the form and forward to the action controller. After the first action the action controller will know the jsp page to forward to since the page would be requesting a page change. The problem is for the first page, since there could be multiple jsp's required to fill the form, which one do you start the entry on? As I mentioned, my current implementation starts with input (normally used for validation). Hope, that helps. Edgar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc status.xml
husted 2002/12/26 17:49:41 Modified:doc status.xml Log: Add link from Roadmap to 1.1b3 proposal. Add Bugzilla links to proposal. Mark items that have already been resolved yeah!/. Revision ChangesPath 1.20 +25 -29jakarta-struts/doc/status.xml Index: status.xml === RCS file: /home/cvs/jakarta-struts/doc/status.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- status.xml24 Dec 2002 19:23:14 - 1.19 +++ status.xml27 Dec 2002 01:49:41 - 1.20 @@ -35,6 +35,24 @@ /section +section href=bugzilla name=Bugzilla Queries + +p +The Struts development teams uses the a href=http://jakarta.apache.org/site/bugs.html;Apache Bug Database/a (Bugzilla) +to manage problem reports and enhancement requests. +For your convenience, here are some common Bugzilla queries: +/p + +ul +lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;product=Strutsamp;order=%27Importance%27;Open reports/a/li +lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_severity=Blockeramp;bug_severity=Criticalamp;bug_severity=Majoramp;bug_severity=Normalamp;bug_severity=Minoramp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Strutsamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=%27Importance%27;Open problem reports/a/li +lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_severity=Enhancementamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Strutsamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=%27Importance%27;Open enhancement requests/a/li +lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=LATERamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Strutsamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=%27Importance%27;Reports to be handled LATER/a/li +/ul + + +/section + section href=struts_1_1 name=Struts 1.1 p @@ -50,35 +68,9 @@ /p p -Remaining tasks: +A proposal for the release of +a href=proposals/release-plan-1.1b3.htmlStruts 1.1 beta 3/a is pending. /p - -ul - -li -Finishing touches on Struts-el -/li - -li -Refactor Tiles to be module aware -/li - -li -Commons-Resource integration -/li - -li -Other routine changes per -a href=http://issues.apache.org/bugzilla/;Bugzilla/a and the -a href=http://nagoya.apache.org/eyebrowse/SummarizeList?listId=41; -Developer mailing list/a. -/li - -/ul - -pA live query of the current outstanding bugs can be found - a href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;product=Strutsamp;order=%27Importance%27;here/a./p - /section section href=struts_1_2 name=Struts 1.2.x @@ -209,6 +201,10 @@ section href=proposals name=Relevant Proposals ul + +li +a href=proposals/release-plan-1.1b3.htmlRelease Plan 1.1-b3/a +/li li a href=../proposals/struts-faces.htmlstruts-faces taglib/a -- To unsubscribe, e-mail: mailto:[EMAIL
cvs commit: jakarta-struts/doc/proposals release-plan-1.1b3.xml
husted 2002/12/26 17:49:54 Modified:doc/proposals release-plan-1.1b3.xml Log: Add link from Roadmap to 1.1b3 proposal. Add Bugzilla links to proposal. Mark items that have already been resolved yeah!/. Revision ChangesPath 1.4 +52 -22jakarta-struts/doc/proposals/release-plan-1.1b3.xml Index: release-plan-1.1b3.xml === RCS file: /home/cvs/jakarta-struts/doc/proposals/release-plan-1.1b3.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- release-plan-1.1b3.xml23 Dec 2002 22:26:34 - 1.3 +++ release-plan-1.1b3.xml27 Dec 2002 01:49:54 - 1.4 @@ -33,7 +33,7 @@ pTherefore, the following release plan is proposed for Struts 1.1 Beta 3: /p ul - liemCode Freeze / Tag Date/em - Sunday, December 29, 2002/li + liemCode Freeze / Tag Date/em - Sunday, December 29, 2002, 23:59:59/li liemRelease Manager/em - Martin Cooper/li liemRelease Announcement/em - To the following mailing lists: ul @@ -70,7 +70,7 @@ pPrior to the release of a subsequent Struts 1.1 release candidate, the following action items must be completed:/p ul - liAll a href=http://nagoya.apache.org/bugzilla/;Bugzilla/a bug reports + liAll a href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_severity=Blockeramp;bug_severity=Criticalamp;bug_severity=Majoramp;bug_severity=Normalamp;bug_severity=Minoramp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfield=%5BBug+creation%5Damp;chfieldfrom=1970-01-01amp;chfieldto=2002-12-22amp;chfieldvalue=amp;product=Strutsamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=Bug+Number;Bugzilla bug reports/a against Struts 1.1 nightly builds MUST be marked as Resolved, with any of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER, REMIND, WORKSFORME)./li @@ -85,84 +85,114 @@ section name=Bugs To Be Addressed href=Bugs - pThe following bugs must be addressed before Final Release of Struts 1.1./p + p + The following bugs must be addressed before Final Release of Struts 1.1. + Checked items have been resolved. + /p table !-- Custom tags -- tr - td colspan=2strongCustom Tags/strong/td + td colspan=3strongCustom Tags/strong/td /tr tr - td width=7511021/td + td nowrap=nowrap[ ]/td + td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=11021;11021/a + /td tdActionForward or lt;html:linkgt; tag does not support absolute URIs/td /tr tr - td width=7512302/td +td nowrap=nowrap[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=12302;12302/a/td tdSporadic error in html:form action attribute/td /tr tr - td width=7515044/td +td nowrap=nowrap[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=15044;15044/a/td tdTaglib - Index Attribute in html:Checkbox doesn't set correctly/td /tr tr - td width=7515196/td +td nowrap=nowrap[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=15196;15196/a/td tdBug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the parameter/td /tr tr - td width=7515451/td +td nowrap=nowrap[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=15451;15451/a/td tdMultiple mapped properties not possible / Direct maps and indexes not possible/td /tr tr - td width=7515601/td +td nowrap=nowrap[x]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=15601;15601/a/td tdtile examples to move to standard webapp location/td /tr !-- Controller -- tr - td colspan=2strongController/strong/td + td colspan=3strongController/strong/td /tr tr - td width=7512871/td +td[x]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=12871;12871/a/td tdExceptionHandler does not obey controller inputForward rule/td /tr tr - td width=7514054/td +td[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=14054;14054/a/td
cvs commit: jakarta-struts/doc/proposals release-plan-1.1b3.xml
husted 2002/12/26 17:53:59 Modified:doc/proposals release-plan-1.1b3.xml Log: Insert #13645 to b3 bug list, as discussed. Revision ChangesPath 1.5 +7 -1 jakarta-struts/doc/proposals/release-plan-1.1b3.xml Index: release-plan-1.1b3.xml === RCS file: /home/cvs/jakarta-struts/doc/proposals/release-plan-1.1b3.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- release-plan-1.1b3.xml27 Dec 2002 01:49:54 - 1.4 +++ release-plan-1.1b3.xml27 Dec 2002 01:53:59 - 1.5 @@ -110,6 +110,12 @@ tdSporadic error in html:form action attribute/td /tr tr +td[ ]/td +td + a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=13645;13645/a/td + tdAdd action attribute to lt;html:linkgt;/td +/tr +tr td nowrap=nowrap[ ]/td td a href=http://issues.apache.org/bugzilla/show_bug.cgi?id=15044;15044/a/td -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el README.txt
dmkarr 2002/12/26 18:23:52 Modified:contrib/struts-el README.txt Log: Removed present and notPresent from the list of tags in the logic library that were NOT ported to struts-el. I forgot to remove them from this list after I implemented them later (because I realized the roles functionality wasn't easily available anywhere else). Revision ChangesPath 1.2 +0 -2 jakarta-struts/contrib/struts-el/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/README.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README.txt26 Sep 2002 04:54:37 - 1.1 +++ README.txt27 Dec 2002 02:23:52 - 1.2 @@ -57,8 +57,6 @@ lessThan c:if, c:when, EL notEmpty c:if, c:when, EL notEqual c:if, c:when, EL -notPresent c:if, c:when, EL -present c:if, c:when, EL Html Tag Library Tags NOT Implemented in Struts-EL -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide index.xml
husted 2002/12/26 18:38:43 Modified:doc/userGuide index.xml Log: Update index with current section numbers. Revision ChangesPath 1.24 +4 -2 jakarta-struts/doc/userGuide/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/index.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- index.xml 24 Dec 2002 01:50:07 - 1.23 +++ index.xml 27 Dec 2002 02:38:43 - 1.24 @@ -170,8 +170,10 @@ lia href=configuration.html#resources_config7.2.2 Message Resources Configuration/a/li lia href=configuration.html#PlugIn_config7.2.3 PlugIn Configuration/a/li lia href=configuration.html#data-source_config7.2.4 Data Source Configuration/a/li -lia href=configuration.html#dd_config_modules7.2.5 Configuring your application for modules/a/li -lia href=configuration.html#module_config-switching7.2.6 Switching Modules/a/li +lia href=configuration.html#dd_config_modules7.3 Configuring your application for modules/a/li +lia href=configuration.html#module_config-switching7.3.3 Switching Modules/a/li +lia href=configuration.html#dd_config7.4 The Web Application Deployment Descriptor/a/li +lia href=configuration.html#config_add7.5 Add Struts Components To Your Application/a/li /ul /li li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
On Thu, 26 Dec 2002, Ted Husted wrote: Ok, I'll update the Roadmap and the B3 plan with the appropriate queries, and add a box next to the bugs we are swatting to indicate their status. This will at least make the static list easier to maintain =:0) I just updated the site with your updated release plan. Given that the plan has changed from what people voted on, do we need to ((re-)re-)vote on the updated release plan? sigh/ I hope not, but I fear so. FYI, we had 9 +1/+0 responses and no -1/-0 responses, so 9 committers responding out of 14 currently listed. -- Martin Cooper Just finished setting a bunch of new equipment, and I'm quite ready to get back to work now =:0) -Ted. Craig R. McClanahan wrote: On Thu, 26 Dec 2002, Ted Husted wrote: Date: Thu, 26 Dec 2002 16:55:34 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised) Craig's message mentions an up to the minute list, which I believe should be a Bugzilla query. I think this is definitely a useful query to have available, but I'm somewhat agreeing with Martin that a dynamic query doesn't really represent an agreed-upon target for a beta release (1.1) or a milestone release (1.2+). I believe that it is useful to have some measure of agreement on which subset of the current Bugzilla entries must be handled. Leaving the list dynamic means that it will essentially never be completed, and that a release will keep getting deferred until a few more bugs get addressed - which sounds suspiciously like one of the things that has delayed beta 3 :-). If something comes in just before the freeze, and it's not a true show stopper, we can just make it LATER, which we should be doing anyway. If we want to get more aggressive about using LATER, the Target Milestone field in Bugzilla is available for identifying *which* future release we think a particular bug report will be resolved in. This will be particularly useful in planning work for 1.2.x releases (which shouldn't necessarily need to be complete clean sweeps of all the outstanding bugs, if we follow the model used for the HTTPD server and Tomcat). I would just like to get out of the habit of dual maintenance of multiple lists. -Ted. Craig PS: I'm looking at the convert to commons-resources issue that we've talked about, but not yet done. Among other things, this needs to be done (if we're going to) before dealing with 11932. I'm also planning on dealing with that one. 12/26/2002 3:40:43 PM, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 25 Dec 2002, Ted Husted wrote: 12/24/2002 6:53:29 PM, Martin Cooper [EMAIL PROTECTED] wrote: The plan doesn't say we're committing to fixing the problem, it says the problem report must be resolved before final release of Struts 1.1. I believe we need to do that, even if we have to mark it LATER because we haven't been able to reproduce it or track it down by the time we're otherwise ready for a final release. Since we already say that under Release Criteria, I'd suggest we drop the Bugs to be Addressed section as redundant and replace the link to Bugzilla with one that will produce the list we need to address. There are a couple of reasons I'm reluctant to do that. * The bug list was added at Craig's suggestion on the vote for the 1.1-b1 release plan. It's based on previous experience with Tomcat releases. See: http://archives.apache.org/eyebrowse/ReadMsg?listName=struts- [EMAIL PROTECTED]msgNo=7086 * I believe we need a somewhat fixed target to aim at, rather than a moving one. If we use a link to Bugzilla rather than a list that we agree upon, then it would presumably mean that if someone submits a new bug report at 23:55 on the proposed release date, we are no longer ready for the release, since the link in the release plan now refers to a non-empty list of bugs that need to be resolved before the release can happen. The use of the STATUS file that Craig introduced before might be a good compromise between using the list in the release plan and using a link to Bugzilla. This file would get updated as bugs get fixed, and if someone believes a new bug also needs to be fixed before release, they can add it to the file. That commit would, as always, be subject to veto if someone else disagrees, thus using the usual code voting mechanism to control the list. -- Martin Cooper Apparently, this is the Bugzilla link on the Roadmap, less the enhancement requests. (Edit the query and select everything but.) http://issues.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_stat
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
I don't really think we need a revote, but if others do you can count in my +1. At this stage, I'm all for marking new bugs as LATER for the next release (whether that be a beta or final). By all means, let's try to knock out the bugs we can between now and the time the beta is cut, but let's cut it none-the-less. (What is the next milestone we're aiming for? 1.1-final? 1.1-beta-4?) Peace Martin Cooper wrote: On Thu, 26 Dec 2002, Ted Husted wrote: Ok, I'll update the Roadmap and the B3 plan with the appropriate queries, and add a box next to the bugs we are swatting to indicate their status. This will at least make the static list easier to maintain =:0) I just updated the site with your updated release plan. Given that the plan has changed from what people voted on, do we need to ((re-)re-)vote on the updated release plan? sigh/ I hope not, but I fear so. FYI, we had 9 +1/+0 responses and no -1/-0 responses, so 9 committers responding out of 14 currently listed. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
