Servlet Exception
Hi all, When I try to display a collection using Struts, I encountred this exception : (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) Illegal target of jump or branch I am using Tomcat 4.0. Can Someone help me Thanks
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 14:38 --- Niall wrote: html:radio property=gender value=male initValue=male/ html:radio property=gender value=female/ ...and presumably if the gender property is null, the initValue would be used rather than the property? Yes, that sounds correct. Joe wrote: from my first look at the suggested JSP syntax, it seems to require a lot of repetition I believe someone else proposed a radiogroup tag which would reduce the repeating the same values again: html:radioGroup property=gender initValue=male html:radio value=male/ html:radio value=female/ /html:radioGroup However, this prevents people from sequentially mixing radio buttons for different properties as you can in HTML, i.e. the following would be impossible: radio name=param1 value=foo radio name=param2 value=bar radio name=param1 value=bar Where Ricardo indicates that creating and populating the form before sending the user to the view is duplicating the work of the Struts Framework, I'd say that we should be making it straightforward to do this step. It's a very common issue and users shouldn't be required to re-solve it. I agree the above should be done, but I feel that it would still not resolve the user's reasonable expectation that, like other HTML taglib elements, the values of an html:radio tag can be initialised in the JSP view. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 15:39 --- Ricardo wrote: I agree the above should be done, but I feel that it would still not resolve the user's reasonable expectation that, like other HTML taglib elements, the values of an html:radio tag can be initialised in the JSP view. I'll concede that this is an asymmetry which might deserve attention, but I'm still concerned about the syntax, and I agree that the radioGroup wrapper element is not really a usable solution. However, having an attribute whose value is only consulted when the underlying form bean's value is null is asymmetric in another way. In other form elements, if you used JSP syntax to specify an initial value, that value would override any existing value in the form bean as well. This is why I always come back to the issue of pre-filling the form bean values in non-validation situations. JSP-level strategies for setting form values are incompatible with the way the html tags re- fill values after validation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
I'm trying to download from the subversion (anonymously) and I keep getting a 501 Not Implemented error. I'm typing the URL correctly and this does not work for any of the projects (including Struts). Could this be something to do my firewall at work? Does subversion use something other than port 80 to communicate? sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NAG - Please commit my patches before subversion switch
As per Craig's suggestion, I will nag the committers to apply the patches I have submitted to Bug #31230. These patches fix 2 of 3 classes that were using deprecated code. The bug needs to remain open, however, because there is still one more class that needs to be fixed. Thanks, sean http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12838 http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12839 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don Sean Schofield wrote: I'm trying to download from the subversion (anonymously) and I keep getting a 501 Not Implemented error. I'm typing the URL correctly and this does not work for any of the projects (including Struts). Could this be something to do my firewall at work? Does subversion use something other than port 80 to communicate? sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NAG - Please commit my patches before subversion switch
On Tue, 28 Sep 2004 11:50:10 -0400, Sean Schofield [EMAIL PROTECTED] wrote: As per Craig's suggestion, I will nag the committers to apply the patches I have submitted to Bug #31230. These patches fix 2 of 3 classes that were using deprecated code. The bug needs to remain open, however, because there is still one more class that needs to be fixed. Then I'd prefer to wait until we have all of the fixes before we apply the patches. The move to SVN shouldn't affect the application of the diffs using the patch utility, so I'm not in a hurry to apply them before the move. -- Martin Cooper Thanks, sean http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12838 http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12839 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Tue, 28 Sep 2004 11:57:20 -0400, Sean Schofield [EMAIL PROTECTED] wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. It might be particular methods being blocked rather than ports. I don't think SVN uses any other ports, but it might use non-standard methods. -- Martin Cooper Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 16:12 --- Maybe a better syntax would be simply a boolean default attribute: html:radio property=gender value=male default=true/ html:radio property=gender value=female/ Niall P.S. The comment I made earlier about the FormTag calling the reset() method when it creates an ActionForm - it does actually do that (missed it first time I looked), so that is another opportunity to set the default value. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem related to Struts-tiles
Hi, I am using tiles in my project .I am using classic layout my tiles-defs.xml which i made have one definition tag like this definition name=site.mainLayout path=/layouts/classicLayout.jsp put name=title value=Tiles Blank Site / put name=header value=/tiles/common/header.jsp / put name=menu value=/tiles/common/menu.jsp / put name=footer value=/tiles/common/footer.jsp / put name=body value=/tiles/body.jsp / /definition now I am extending this definition tag with another definition definition name=site.homeLayout extends=site.mainLayout put name=body value=/tiles/homebody.jsp / /definition Now when in my first definition i have one menu.jsp on clicking on that menu i call extended definition. Now problem it refresh the entire page instead of body page. I want only body content should refresh rest header,footer and menu should remain like this just like when we use frames. kindlly suggest what should i do. regards thanks Anant Regards and thanks, Anant Anant Das Agarwal IBM Global Services India Pvt Ltd X1-7, Block-EP/GP, Sector-V Salt Lake Electronic Complex Kolkata 700091 +91 33 2357 9110 x 3405
Re: [ANN] CVS to Subversion Conversion Wednesday
CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Port 80, just like any other web server. Committers will use 443 (SSL) for authentication. Don Greg Reddin wrote: CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Mind that SVN uses WebDAV standard, not simple HTTP WWW standard. Your firewall might be blocking PUT, MKCOL, OPTIONS, PROPFIND, LOCK and UNLOCK. its usual. Respectfully, Jose Luiz Peleteiro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NAG - Please commit my patches before subversion switch
OK. I will try to come up with a patch for the third class and email the list when its done. Thanks for the response. sean Martin Cooper wrote: On Tue, 28 Sep 2004 11:50:10 -0400, Sean Schofield [EMAIL PROTECTED] wrote: As per Craig's suggestion, I will nag the committers to apply the patches I have submitted to Bug #31230. These patches fix 2 of 3 classes that were using deprecated code. The bug needs to remain open, however, because there is still one more class that needs to be fixed. Then I'd prefer to wait until we have all of the fixes before we apply the patches. The move to SVN shouldn't affect the application of the diffs using the patch utility, so I'm not in a hurry to apply them before the move. -- Martin Cooper Thanks, sean http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12838 http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12839 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Tue, 28 Sep 2004, Greg Reddin wrote: CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? It uses 3690, Salva Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31455] New: - null Boolean field value in ActionForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31455 null Boolean field value in ActionForms Summary: null Boolean field value in ActionForms Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When there is a Boolean (wrapper class) field inside an ActionForm that receives a checkbox value, it returns true for a checked box and null for an unchecked box. It should return false instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Subversion can actually be exposed multiple ways. One such way is to use its built-in svnserve server which does listen over 3690. Subversion can also be exposed via WebDAV as an Apache 2.0 module. In the latter case, it can listen at any port Apache is configured to listen on, usually 80 and/or 443. Apache Software Foundation's Subversion server, svn.apache.org, does in fact use the Apache WebDAV module and listens at 80 for non-authenticated users, and 443 for authenticated users (usually committers). svnserve and port 3690 are not used at all. Don Salvador Trujillo Gonzalez wrote: On Tue, 28 Sep 2004, Greg Reddin wrote: CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? It uses 3690, Salva Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31455] - null Boolean field value in ActionForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31455 null Boolean field value in ActionForms [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 17:07 --- It cannot. Note that there is *nothing* in the request to indicate that a checkbox is not checked; in this situation, the parameter is simply not present at all. A value for a checkbox is send in the request *only* if the checkbox is checked. So there is no way to change the value of a checkbox field from null to false if there is nothing in the request to indicate that the checkbox was unchecked. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NAG - Please commit my patches before subversion switch
No, thank you for the patches! -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 12:53 PM Subject: Re: NAG - Please commit my patches before subversion switch OK. I will try to come up with a patch for the third class and email the list when its done. Thanks for the response. sean Martin Cooper wrote: On Tue, 28 Sep 2004 11:50:10 -0400, Sean Schofield [EMAIL PROTECTED] wrote: As per Craig's suggestion, I will nag the committers to apply the patches I have submitted to Bug #31230. These patches fix 2 of 3 classes that were using deprecated code. The bug needs to remain open, however, because there is still one more class that needs to be fixed. Then I'd prefer to wait until we have all of the fixes before we apply the patches. The move to SVN shouldn't affect the application of the diffs using the patch utility, so I'm not in a hurry to apply them before the move. -- Martin Cooper Thanks, sean http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12838 http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12839 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31455] - null Boolean field value in ActionForms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31455 null Boolean field value in ActionForms --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 17:49 --- You should be setting it to false in the reset() method. That will guarantee you to get the results you want. It's all in the user guide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 18:52 --- Ricardo wrote: That seems fine: could we not make the radio/radiogroup initValue attribute satisfy the standard HTML taglib 'value' contract instead? That contract says that if value is supplied, use it, without consulting the underlying bean; so in the case where initValue was implemented, when an invalid form was re-presented to the user, the initValue would be consulted again regardless of what the user had selected upon her prior submission. Is this what you're looking for? I wouldn't want to do that to a user. Note that the same issue applies to checkbox, multibox, and select, none of which have this kind of mechanism. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 19:59 --- Joe wrote: That contract says that if value is supplied, use it, without consulting the underlying bean; so in the case where initValue was implemented, when an invalid form was re-presented to the user, the initValue would be consulted again regardless of what the user had selected upon her prior submission. Not sure what you are getting at with the above, but surely the same would already apply to those tags (text, hidden, password) that do allow developers to set the initial values in the JSP. Note that the same issue applies to checkbox, multibox, and select, none of which have this kind of mechanism. But, not the same as the text, hidden, password and textarea elements, which all have an initialisation mechanism. I think the problem is that the user not only expects the radio tag to have a initial value attribute, but is also used to setting initial values through the selected attribute in the page itself as well. I think this is a case of mixed design: some initial values must be set in the control layer but some can also be set in the JSP form (view layer) which leads to confusion and frustration. We should either allow all html elements to be intialised in the view layer or only allow users to initialise values in the control layer in which case some framework to do this must be created. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 20:17 --- In so far as there is a mixed design, it's simply a side effect of the HTML input form model, which has distinctly different models for elements which present an array of choices to the user as compared to elements which accept open user input. Ricardo wrote: Joe wrote: That contract says that if value is supplied, use it, without consulting the underlying bean; so in the case where initValue was implemented, when an invalid form was re-presented to the user, the initValue would be consulted again regardless of what the user had selected upon her prior submission. Not sure what you are getting at with the above, but surely the same would already apply to those tags (text, hidden, password) that do allow developers to set the initial values in the JSP. It's true, it does already apply, and it's true, this is why I think that developers should not be setting initial values in the JSP. In my mind, the main reason to use the Struts HTML tags is to facilitate automatically re-filling form fields with user input when that input was not accepted as valid. As for a framework for prefilling values in the controller layer instead of the view layer, I have posted some specific examples about how I've solved that problem in a current project to struts-dev, looking for feedback and refinements from people with a goal of building out Struts to support it. See http:// article.gmane.org/gmane.comp.jakarta.struts.devel/22034 and please feel free to comment/criticize/ etc. In the meantime, I'm not saying that I would veto changes to support some kind of JSP-level pre-filling of select-type elements; I just haven't seen anything that I think is a really good solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31365 Add initValue attribute to html:radio tags --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 20:29 --- Joe wrote: In the meantime, I'm not saying that I would veto changes to support some kind of JSP-level pre-filling of select-type elements; I just haven't seen anything that I think is a really good solution. I think Niall's previous idea of having a boolean selected attribute offers the simplest and most natural (i.e. as close to the original HTML tags) solution. I can create a patch but it's up to you, the struts contributors, to decide whether you think the problem is large enough to warrant this. Certainly, I think developers could become frustrated by the inconsitincies in HTML taglib. As a stop-gap before a framework such as you suggest is implemented, I think this seem reasonable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31230] - Multiple classes using deprecated DefinitionsUtil class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31230. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31230 Multiple classes using deprecated DefinitionsUtil class --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 01:39 --- Created an attachment (id=12888) Fixes deprecated refs in TilesPlugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31230] - Multiple classes using deprecated DefinitionsUtil class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31230. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31230 Multiple classes using deprecated DefinitionsUtil class --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 01:40 --- Third and final patch has been submitted. Once patches are applied, bug should be considered complete. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts
Tom Roche Sun, 21 Mar 2004 13:49:45 -0500 summary: McClanahan should clearly state *in some major publication* OK, mebbe it'll get cited in some major publication :-) * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 I think either of us would rather be developing Struts than evangelizing Struts. Tom Roche Mon, 22 Mar 2004 08:00:00 -0500 This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. So I am pleased to note: http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Now I can whack the locals who say Struts? Isn't that what Faces replaces? :-) Thanks, Tom hoping to tool for Tiles this rev, at last Roche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-1.2.4 not archived at ibiblio.
At 8:31 AM -0500 9/27/04, Antony Joseph wrote: Is there a way we can get struts-1.2.4 archived at ibiblio. The current verion available at the site is struts-1.2.2 I have tried to use maven's jar:deploy goal, and while it worked for struts, I was not able to pass the tests for struts-el. I think this is just a Maven quirk -- in fact, I think it's just that the Maven project.xml file is configured to run the Struts EL tests as JUnit tests, not Cactus tests. For now, as a pragmatic matter, I have simply copied struts.jar and struts-el.jar from the binary distribution into the iBiblio mirror. In some sense, this may be more correct, since those are official and anything built using Maven might not be identical. So maybe it's just as well. I'd be happy to get feedback on that from other developers, and especially committers. Manually copying all the TLD files including changing their version numbers seems kind of tedious. I would do it if anyone needed it, but at this point I'm not really sure why TLDs are stored in Maven repositories. Sorry for the delays, and please let me know if there are any issues. Remember that I copied these to a mirror, so there may be a brief delay before they are actually visible on iBiblio. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: coming out for JSF + Struts
You cannot *imagine* how many people have asked me to clarify this relationship :-). I hope this blog entry helps, but (as I noted) the future of Struts is decided here, not by anything I, or anyone else, might opine elsewhere. Craig On Tue, 28 Sep 2004 22:15:57 -0400, Thomas L Roche [EMAIL PROTECTED] wrote: Tom Roche Sun, 21 Mar 2004 13:49:45 -0500 summary: McClanahan should clearly state *in some major publication* OK, mebbe it'll get cited in some major publication :-) * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 I think either of us would rather be developing Struts than evangelizing Struts. Tom Roche Mon, 22 Mar 2004 08:00:00 -0500 This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. So I am pleased to note: http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Now I can whack the locals who say Struts? Isn't that what Faces replaces? :-) Thanks, Tom hoping to tool for Tiles this rev, at last Roche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Downloading Applications and Struts
A downloading application utilizing Struts, in my opinion, like the uploading applications, should have its basic classes somewhere else, like uploading is in commons. Such an application, in my opinion, should merely present an interface that subclasses of Struts Actions can, directly or indirectly, reference. Such an application, also in my opinion, should distinguish and decouple distinct behaviors as, for example, the distinction between the io functions and the management functions such as access control, choice between zip, folder and database sources, etc. The demands of such applications, in my opinion, are too different from the purpose of the Action class to work well in the end in an Action class. Shouldn't, for example, any cool solution for either downloading or uploading in the end be multithreaded? Is getting or managing the receipt or sending of a file really within the proper scope of the Action class? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Applications and Struts
You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements. I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does. The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much common functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity? Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a one-stop shopping proposition. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Michael McGrady wrote: A downloading application utilizing Struts, in my opinion, like the uploading applications, should have its basic classes somewhere else, like uploading is in commons. Such an application, in my opinion, should merely present an interface that subclasses of Struts Actions can, directly or indirectly, reference. Such an application, also in my opinion, should distinguish and decouple distinct behaviors as, for example, the distinction between the io functions and the management functions such as access control, choice between zip, folder and database sources, etc. The demands of such applications, in my opinion, are too different from the purpose of the Action class to work well in the end in an Action class. Shouldn't, for example, any cool solution for either downloading or uploading in the end be multithreaded? Is getting or managing the receipt or sending of a file really within the proper scope of the Action class? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Applications and Struts
On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements. The distinction you are drawing is indeed correct, and significant. However ... I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does. The proposed example is a good first step, but the hard part of building a framework, as opposed to an application, is figuring out where to define the extension points. An example issue relevant to the current proposal -- what if I want to load my data from somewhere other than a database? If's fine to generalize the names of the tables and columns, but an extensible framework for building download-some-recorded-data portions of an application will probably need to define some interface that includes ways to abstract where the data comes from, what the output content type should be, how to determine the content length, whether (and how) to create a Content-Disposition header, and a myriad of other details. The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much common functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity? I would suggest that downloading *static* content (from a file on the server) is something that a web server, or a servlet container, already takes care of -- it doesn't need any extra support from a framework like Struts. The window of opportunity is around static data that is stored in a fashion not supported by the default functionality of the server on which the application is running. Of course, one could also argue that serving static content doesn't need an app framework at all -- it can be implemented (for example) by a standalone servlet that is totally unaware of Struts. That is also a reasonable position; one would have to articulate why this functionality needs to be incorporated into the controller for the user interactions. Such arguments can be made, but I don't think they are going to be universally applicatabe. Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a one-stop shopping proposition. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect. I agree with you that the o.a.s.actions package is built *on top of* the framework, instead of *being* the framework. However, the proposed code doesn't strike me as sufficiently general, yet, for inclusion -- perhaps we could look more at defining the general problem of how can we create an abstraction for a response that might be acquired from some resource, instead of being dynamically created by the execution of a JSP page. In the purest sense, the fact that you can return null from an Action (indicating that the response has already been created) means that Struts itself doesn't need anything extra. That being said, a design pattern standard action, equally at home with data extracted from a database, a directory server, an XSLT transformation, static files, web services calls, a return from an EJB, or execution of some method on a JavaBean, ... would be more appropriate for inclusion in Struts itself. Such an approach (defining a Provider interface of some sort) would also enable the use of any of the currently popular IoC frameworks to provide an appropriate implementation, instead of burying all the functionality for JDBC access directly in the proposed Action itself. Is it feasibe to
Re: Downloading Applications and Struts
Frank W. Zammetti wrote: You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements. The next things, though, would be a forms package, etc. There would be one, I would bet, if some people had thought of it! LOL ;-) I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does. Downloading is just as complex, I think, and fraught with danger. I don't think Martin's approach does exactly what you think, but that is not the issue. I could be right, or you could be right. If we are arguing about whether we like it, it probably should be a CHOICE somehow but not in the framework proper. I am FOR making more choices available. Just HOW to do it is the question. The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much common functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity? Somethings, however, are useful and have NOTHING to do with Struts. The ImageButtonBean is an example of this. I also think that Martin's DownloadAction is an example of this. Those things should be available, of course. I am NOT saying they shouldn't. Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? But, there are Strust oriented patterns and patterns that are not related to the framework. That is what I am saying. If you have a pattern that is (1) related to the Struts framework code and (2) a general sort of functionality that is needed, then it belongs. Other things that really are choices that some would like and others would hate should be available but not wedded to the framework in a way so that they have to be kept in there or deprecated. Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a one-stop shopping proposition. We could have MORE NOT LESS solutions if we did not put particular solutions into the framework which thereby freezes out competing and maybe better solutions. This is a real problem in my view. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect. I would never add something that is a mere solution to a non-framework problem. Thanks for the discussion, Frank. I appreciate it. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Applications and Struts
Craig McClanahan wrote: The proposed example is a good first step, but the hard part of building a framework, as opposed to an application, is figuring out where to define the extension points. An example issue relevant to the current proposal -- what if I want to load my data from somewhere other than a database? If's fine to generalize the names of the tables and columns, but an extensible framework for building download-some-recorded-data portions of an application will probably need to define some interface that includes ways to abstract where the data comes from, what the output content type should be, how to determine the content length, whether (and how) to create a Content-Disposition header, and a myriad of other details. I think this is what Martin's proposed DownloadAction seeks to do, that is, define a valid extension point. I want to be clear on what we are actually discussing... At this point we're NOT talking about my original submitted proposal, which did deal specifically with serving from a database (because my original thinking was that it could be done in a generic way). Martin's suggested class has since bumped my original proposal, but instead I submitted a sample app that made use of Martin's class. This is where this discussion is today. Just wanted to be sure we're all on the same page :) I would suggest that downloading *static* content (from a file on the server) is something that a web server, or a servlet container, already takes care of -- it doesn't need any extra support from a framework like Struts. The window of opportunity is around static data that is stored in a fashion not supported by the default functionality of the server on which the application is running. I would agree with this without question. The situation I'm trying to deal with (and what was the genesis for my original proposal) is really serving from a database. I have a system at work that I wrote that serves images from a database (for client customization) as well as serving PDF's generated on-the-fly, so that's being done from memory. The images are certainly static and could be handled by the web server (why they aren't in this case is an environment-specific issue). It is this area, the semi-static and the dynamic BLOB-type downloads that I think there is an opportunity to do something, as you said. I would durther make the argument that this is such a common activity that to include it in Struts in some fashion is beneficial to all that use Struts. Of course, one could also argue that serving static content doesn't need an app framework at all -- it can be implemented (for example) by a standalone servlet that is totally unaware of Struts. That is also a reasonable position; one would have to articulate why this functionality needs to be incorporated into the controller for the user interactions. Such arguments can be made, but I don't think they are going to be universally applicatabe. Agreed. There can be such a variety of ways of doing this that a general-purpose solution probably isn't possible. The simple question though is at what point is it serving enough people to validate it's addition. I think Martin's approach, perhaps with just a little bit of tweaking in some ways, is sufficiently generic and extensible enough to warrant inclusion. I think my sample app, showing the serving of images from the file system as well as from a database, proves the flexibility of the approach. Serving from virtually any other source should be a simple matter. I agree with you that the o.a.s.actions package is built *on top of* the framework, instead of *being* the framework. However, the proposed code doesn't strike me as sufficiently general, yet, for inclusion -- perhaps we could look more at defining the general problem of how can we create an abstraction for a response that might be acquired from some resource, instead of being dynamically created by the execution of a JSP page. In the purest sense, the fact that you can return null from an Action (indicating that the response has already been created) means that Struts itself doesn't need anything extra. That being said, a design pattern standard action, equally at home with data extracted from a database, a directory server, an XSLT transformation, static files, web services calls, a return from an EJB, or execution of some method on a JavaBean, ... would be more appropriate for inclusion in Struts itself. Such an approach (defining a Provider interface of some sort) would also enable the use of any of the currently popular IoC frameworks to provide an appropriate implementation, instead of burying all the functionality for JDBC access directly in the proposed Action itself. I don't think I disagree with that thought, but I do see some statements here that are leading me to believe your thinking of my original sample app, not the one based on Martin's DownloadAction. I'd be interested in
Re: Downloading Applications and Struts
Michael McGrady wrote: I would never add something that is a mere solution to a non-framework problem. But this is really the crux of the debate, and is also the reason I find myself simultaneously agreeing and disagreeing with you :) The distinction between what is a mere solution to a non-framework problem and what can be properly thought of as an extension to a framework is generally not at all an easy question to answer. Much of what you say I think hinges on your belief in what belongs and what doesn't, not concrete technical issues. Seems like an obvious statement, but I'm not sure it is... For instance, you keep bringing up the ImageButtonBean, and to be honest I don't know anything about it, so I can't comment on whether I think your right or not technical-speaking. I'm sure there's been a lot of debate about whether including it is right or not. And who's to say, strictly speaking who's right? Only the committers really in the end. What criteria is really right to decide by? I've expressed my criteria already... Any addition shouldn't add any unnecassery work for a developer if the addition isn't used, it shouldn't have any performance or load impact if not used and it should address a commonly-encountered issue. How you define commonly-encountered can make all the difference... Is something that 10% of developers run into common enough? 25%? 50%? 90%? Above what percentage is valid and below invalid? Tough to say. You've said that you believe Struts is going in the wrong direction in terms of what is included... Can you give some concrete examples, aside from the ImageButtonBean, to substantiate this? You might be completely right and might get a lot of people rallying to your position, but it's hard to say without more precise details. Otherwise it's really just a gut feeling, which is fine, but is no more valid than anyone else' gut feeling I think (mine very much included!) Thanks for the discussion, Frank. I appreciate it. Michael You as well Michael. Healthy debate is, well, HEALTHY! :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Applications and Struts
Way down there... On Tue, 28 Sep 2004 21:51:55 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements. The distinction you are drawing is indeed correct, and significant. However ... I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does. The proposed example is a good first step, but the hard part of building a framework, as opposed to an application, is figuring out where to define the extension points. An example issue relevant to the current proposal -- what if I want to load my data from somewhere other than a database? If's fine to generalize the names of the tables and columns, but an extensible framework for building download-some-recorded-data portions of an application will probably need to define some interface that includes ways to abstract where the data comes from, what the output content type should be, how to determine the content length, whether (and how) to create a Content-Disposition header, and a myriad of other details. The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much common functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity? I would suggest that downloading *static* content (from a file on the server) is something that a web server, or a servlet container, already takes care of -- it doesn't need any extra support from a framework like Struts. The window of opportunity is around static data that is stored in a fashion not supported by the default functionality of the server on which the application is running. Of course, one could also argue that serving static content doesn't need an app framework at all -- it can be implemented (for example) by a standalone servlet that is totally unaware of Struts. That is also a reasonable position; one would have to articulate why this functionality needs to be incorporated into the controller for the user interactions. Such arguments can be made, but I don't think they are going to be universally applicatabe. Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a one-stop shopping proposition. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect. I agree with you that the o.a.s.actions package is built *on top of* the framework, instead of *being* the framework. However, the proposed code doesn't strike me as sufficiently general, yet, for inclusion -- perhaps we could look more at defining the general problem of how can we create an abstraction for a response that might be acquired from some resource, instead of being dynamically created by the execution of a JSP page. In the purest sense, the fact that you can return null from an Action (indicating that the response has already been created) means that Struts itself doesn't need anything extra. That being said, a design pattern standard action, equally at home with data extracted from a database, a directory server, an XSLT transformation, static files, web services calls, a return from an EJB, or execution of some method on a JavaBean, ... would be more appropriate for inclusion in Struts itself. Such an approach (defining a Provider interface of some sort) would also enable the use of any of the currently popular
