[Apache Struts Wiki] Updated: StrutsRelease122
Date: 2004-09-01T23:33:29 Editor: MartinCooper [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsRelease122 URL: http://wiki.apache.org/struts/StrutsRelease122 Give James credit, even if it is after the fact. Change Log: -- @@ -10,7 +10,7 @@ == Release Manager == -The release manager is '''add name here''' +The release manager is '''James Mitchell''' == Issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
It's more than a thought ... I was about three keystrokes from including this in my proposal to be forward looking on servlet 2.4 and JSP 2.0 :-). I'd love to see Servlet2.4 and JSP2.0 be the minimum. It was mentioned before that several of the 'itches' that the committers have revolve around more recent versions of the specs. I would think that this logic could also be applied to potential contributors who have been sitting on the sidelines waiting to figure out how to get involved. Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
It's more than a thought ... I was about three keystrokes from including this in my proposal to be forward looking on servlet 2.4 and JSP 2.0 :-). I'd love to see Servlet2.4 and JSP2.0 be the minimum. It was mentioned before that several of the 'itches' that the committers have revolve around more recent versions of the specs. I would think that this logic could also be applied to potential contributors who have been sitting on the sidelines waiting to figure out how to get involved. Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too. Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide release-notes-1.2.1.xml release-notes.xml
niallp 2004/09/02 05:24:30 Modified:doc/userGuide release-notes-1.2.1.xml release-notes.xml Log: Release note corrections Revision ChangesPath 1.4 +3 -3 jakarta-struts/doc/userGuide/release-notes-1.2.1.xml Index: release-notes-1.2.1.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes-1.2.1.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- release-notes-1.2.1.xml 2 Sep 2004 02:00:24 - 1.3 +++ release-notes-1.2.1.xml 2 Sep 2004 12:24:30 - 1.4 @@ -18,7 +18,7 @@ li codeINSTALL.txt/code - Brief installation instructions. For more detail, see the codeStruts User Guide/code, either through the Struts Documentation application or online at - a href=http://jakarta.apache.org/struts/;http://jakarta.apache.org/struts//a./li + a href=http://struts.apache.org/;http://struts.apache.org//a./li li codeLICENSE.txt/code - The Apache Software Foundation license that defines the terms under which you can use Struts (and other software licensed by Apache)./li li @@ -117,10 +117,10 @@ p strongNew Configuration DTD/strong - The code - a href=http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd;struts-config_1_2.dtd/a + a href=http://struts.apache.org/dtds/struts-config_1_2.dtd;struts-config_1_2.dtd/a /code is preferred to the deprecated Struts Configuration 1.1 DTD. The new DTD adds two new elements lt;display-namegt; and lt;descriptiongt; to the struts-config element. These elements are for use by struts config file tools and document generation. In the Struts 1.2.x series, existing Struts configuration files can be loaded using either DTD version./p p -strongNew Committers/strong - We are pleased to welcome Steve Raeburn, Don Brown, and Joe Germuska to the team of Struts Committers./p +strongNew Committers/strong - We are pleased to welcome Steve Raeburn, Don Brown, Joe Germuska and Niall Pemberton to the team of Struts Committers./p p strongStruts-Chain/strong - Still experimental, this new contrib package utilizes the new Chain of Responsibilty package in the Jakarta Sandbox to create a new breed of RequestProcessor. Look for this to become the default implementation in a future release./p p 1.63 +3 -3 jakarta-struts/doc/userGuide/release-notes.xml Index: release-notes.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v retrieving revision 1.62 retrieving revision 1.63 diff -u -r1.62 -r1.63 --- release-notes.xml 2 Sep 2004 02:00:24 - 1.62 +++ release-notes.xml 2 Sep 2004 12:24:30 - 1.63 @@ -18,7 +18,7 @@ li codeINSTALL.txt/code - Brief installation instructions. For more detail, see the codeStruts User Guide/code, either through the Struts Documentation application or online at - a href=http://jakarta.apache.org/struts/;http://jakarta.apache.org/struts//a./li + a href=http://struts.apache.org/;http://struts.apache.org//a./li li codeLICENSE.txt/code - The Apache Software Foundation license that defines the terms under which you can use Struts (and other software licensed by Apache)./li li @@ -115,10 +115,10 @@ p strongNew Configuration DTD/strong - The code - a href=http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd;struts-config_1_2.dtd/a + a href=http://struts.apache.org/dtds/struts-config_1_2.dtd;struts-config_1_2.dtd/a /code is preferred to the deprecated Struts Configuration 1.1 DTD. The new DTD adds two new elements lt;display-namegt; and lt;descriptiongt; to the struts-config element. These elements are for use by struts config file tools and document generation. In the Struts 1.2.x series, existing Struts configuration files can be loaded using either DTD version./p p -strongNew Committers/strong - We are pleased to welcome Steve Raeburn, Don Brown, and Joe Germuska to the team of Struts Committers./p +strongNew Committers/strong - We are pleased to welcome Steve Raeburn, Don Brown, Joe Germuska and Niall Pemberton to the team of Struts Committers./p p strongStruts-Chain/strong - Still experimental, this new contrib package utilizes the new Chain of Responsibilty package in the Jakarta Sandbox to create a new breed of RequestProcessor. Look for this to become the default implementation in a future release./p p
cvs commit: jakarta-struts/contrib/struts-jericho OVERVIEW.txt README.txt
jmitchell2004/09/02 05:41:52 Modified:contrib/struts-jericho OVERVIEW.txt README.txt Log: quick spell-check Revision ChangesPath 1.5 +2 -2 jakarta-struts/contrib/struts-jericho/OVERVIEW.txt Index: OVERVIEW.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/OVERVIEW.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- OVERVIEW.txt 19 Dec 2003 02:31:05 - 1.4 +++ OVERVIEW.txt 2 Sep 2004 12:41:52 - 1.5 @@ -1,7 +1,7 @@ -COMPONENT OVERVIEW- Configuration registry -* At initialiation, each request adapter (servlet, filter, et cetera), adds its configuration to a single registry at a global location under a unique key. +* At initialization, each request adapter (servlet, filter, et cetera), adds its configuration to a single registry at a global location under a unique key. Command Context * Extends CoR Context to encapsulate framework members needed to process request and render response @@ -37,7 +37,7 @@ * Invalid * MappingHandler * Command | Script - * Invoke buiness logic + * Invoke business logic * Affect context state * Identify resource to render response * Location 1.10 +6 -6 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- README.txt19 Dec 2003 01:05:50 - 1.9 +++ README.txt2 Sep 2004 12:41:52 - 1.10 @@ -8,7 +8,7 @@ * Providing working base implementations for all core components. -* Encapsulating alll path references within Location objects (fka ActionForwards)and referring only to Locations from all other objects. +* Encapsulating all path references within Location objects (aka ActionForwards)and referring only to Locations from all other objects. * Providing additional extension points from core components so that the Inversion of Control pattern is fully realized. (e.g., a populate method for the FormHandler.) @@ -16,13 +16,13 @@ * Retain optional access to servlet/portlet objects so that applications can be free to do whatever they need to do. --Backward Compatability- +-Backward Compatibility- -Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible. +Jericho is a revolution and backward compatibility with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practical, so that Jericho is available to the widest community possible. -Taglibs/Tools- -JSP taglibs and other presention tools will be packaged separately from the core controller classes. Tags and tools can access the framework through a StrutsContext object passed through the request, rather than searching through the servlet or portlet contexts. +JSP taglibs and other presentation tools will be packaged separately from the core controller classes. Tags and tools can access the framework through a StrutsContext object passed through the request, rather than searching through the servlet or portlet contexts. -ActionForms/Actions, et al- @@ -50,7 +50,7 @@ * Utilize protocols in resource paths. An mapped path would look like mapping://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. -* Combine form-bean and validator-form configurations. A single element would allow everything Struts knowns about a form to be configured in one place. +* Combine form-bean and validator-form configurations. A single element would allow everything Struts knows about a form to be configured in one place. * Integrate Tiles definitions into core configuration. @@ -58,7 +58,7 @@ * Utilize JodaBeans http://www.joda.org/ as a foundation class for core components. -* Load all configuration defaults form a core.properties file so that less is hardcoded, including a PlugIn class to bootstrap loading the core configuraiton. +* Load all configuration defaults form a core.properties file so that less is hardcoded, including a PlugIn class to bootstrap loading the core configuration. * Ensure that all framework objects in 2.0 have consistent factory-based mechanisms to instantiate instances.
cvs commit: jakarta-struts/contrib/struts-jericho project.properties
jmitchell2004/09/02 06:04:23
Modified:contrib/struts-jericho project.properties
Log:
fix url
Revision ChangesPath
1.2 +1 -1 jakarta-struts/contrib/struts-jericho/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties17 Dec 2003 20:49:28 - 1.1
+++ project.properties2 Sep 2004 13:04:23 - 1.2
@@ -11,4 +11,4 @@
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
-maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
+maven.xdoc.developmentProcessUrl=http://struts.apache.org/status.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsShortTermPlans
Date: 2004-09-02T06:05:22 Editor: JamesMitchell [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShortTermPlans URL: http://wiki.apache.org/struts/StrutsShortTermPlans no comment Change Log: -- @@ -1,3 +1,9 @@ To help coordinate our efforts, Struts Committers and other active developers can note their short term plans here. For any one individual, this should be a brief list of one to three items. + +James Mitchell - I am currently spending time in the following areas: + * tweaking the commons-resource (sandbox) project (mostly the database implementations) + * helping with the Struts tests (which are usefull, but overengineered, admittedly my own fault) + * Struts 2.0 discussions + Craig R. nowiki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I'm now listed as a PMC member
-Original Message- From: Alan Mehio [mailto:[EMAIL PROTECTED] Congradulation from Alan Best Luck from me Alan Mehio London Niall Pemberton [EMAIL PROTECTED] wrote: The user guide was updated recently and the Committer section has been removed and I now appear in the PMC Member section. http://struts.apache.org/volunteers.html I assume this is a mistake ? Niall [ Reading my mail 24+ hours too late as usual ] Congratulations from me as well. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31015] New: - Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26
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=31015. 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=31015 Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26 Summary: Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26 Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Struts-Faces Library AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am running the struts-faces2 example (Struts+Faces+Tiles) via the struts-faces2.war file which is included with the struts-faces distribution (nightly build). The WAR file seems to deploy fine and I don't get any error messages. I am also able to use the 'Register' function without any errors. However, when I try to access the 'Log On' function I obtain the stack trace listed below. I am running Tomcat 5.0.26 (bundled within JBoss 3.2.5) on Red Hat Fedora. All our existing 'pure' Struts applications run fine in the exact same environment. I am also using August 31st nightly build of struts-faces. Regards, Piero __ Stack Trace: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:372) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) root cause java.lang.NullPointerException javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683) javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324) javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591) javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478) org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132) org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) ___ The full stack trace reads as follows: 2004-09-02 09:36:22,886 472097 ERROR [org.jboss.web.localhost.Engine] (http-0.0.0.0-8180-Processor2 4:) ApplicationDispatcher[/struts-faces2] Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683) at javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324) at javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591) at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478) at org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132) at org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104) at
[Apache Struts Wiki] Updated: StrutsShortTermPlans
Date: 2004-09-02T07:11:57 Editor: JamesMitchell [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShortTermPlans URL: http://wiki.apache.org/struts/StrutsShortTermPlans no comment Change Log: -- @@ -5,5 +5,14 @@ * helping with the Struts tests (which are usefull, but overengineered, admittedly my own fault) * Struts 2.0 discussions +and my TODO list includes: + * enhancement to the Spring's ContextLoaderPlugin that let's you reuse your bundle without having to declare it in 2 (or more) places + * Struts plugin that let's you use the commons-resources.jar with your existing Struts 1.1 projects + * Struts plugin[1] that let's you edit (via browser popup) all messages accessed in a give request +([1] *only* works for Database impls - you would see a small [edit] link beside any rendered messages, and a list of all keys accessed at the bottom of the page) + + + + Craig R. nowiki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
display collection using logic:iterate
Hello, in struts , i retrieve a collection of data from database and set the data in formbean as a collection . and i try to display the collection in the respective textfields.[ set each value in textfield], for that i used logic:iterate tag and bean:write and html:text tags. but i am not able to display the value in textfield
display collection using logic:iterate
in struts , i retrieve a collection of data from database and set the data in formbean as a collection . and i try to display the collection in the respective textfields.[ set each value in textfield], for that i used logic:iterate tag and bean:write and html:text tags. but i am not able to display the value in textfield
Re: Struts and Escaping Special Charachters in HTML
At 4:50 PM +0200 9/2/04, Hamrita Sami wrote: Hello, does Struts support escaping special charachters for HTML GUIs (e.g. ü -- uuml;) when using its custom tags library? If yes, how to enable that feature then? Struts doesn't convert characters to HTML entities. Instead, you should control the character encoding of your pages so that the characters can be displayed correctly without entities. A general easy way to do this with JSPs is to set the content-type of the page with a JSP @page directive like this: %@ page contentType=text/html; charset=UTF-8 % Of course, you may need to use a different charset, but UTF-8 is a pretty good default. There are other ways to set the character encoding, but this one is simplest to me. Note that if you use tiles or other JSP include strategies, only the first content-type is honored - it is ignored in pages that write to an output stream that already has been started. Hope this helps. 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
DO NOT REPLY [Bug 31021] New: - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) Summary: *old* URI for the *.tlds (including for contrib/ (faces el)) Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Alternative XMLs for TLDs with old URI; see attached ZIP-file Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:04 --- Created an attachment (id=12607) all XMLs in a ZIP-file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:05 --- Created an attachment (id=12608) struts-bean.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:05 --- Created an attachment (id=12609) bean-el - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:06 --- Created an attachment (id=12611) html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:07 --- Created an attachment (id=12612) html-el - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
Ah, now I see... thanks, over I changed all xmls for the TLDs to *old* URI, I created a bugzilla-ticket for it; so you will be able to put old AND new URI to JAR$/META-INF/ URL for Bug #31021 http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 Regards, Matthias -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 6:28 AM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp On Wed, 1 Sep 2004 18:45:22 -0400, Deadman, Hal [EMAIL PROTECTED] wrote: Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: That was exactly my point. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Otherwise, a Struts 1.1 application that relies on the implicit TLD registration done by the container (i.e. *not* listing the TLDs explicitly in web.xml) will go down in flames when run against Struts 1.2.x, unless you go fix the taglib directives in every single page. Basically, it's the same reason that Struts 1.2.x accepts and processes 1.0 and 1.1 versions of struts-config.xml files ... so that older apps can run with minimal changes when you upgrade Struts. It turns out that this doesn't matter for the particular commit message I replied on (which only changed the URI for the struts-faces TLD), but it's an important backwards compatibility principle in general. Craig - 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 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:07 --- Created an attachment (id=12614) logic-el - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:08 --- Created an attachment (id=12616) tiles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:08 --- Created an attachment (id=12617) tiles-el - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
Martin, ok, sorry... for bothering you all. I misunderstand the mail(s) before. Regards, Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:09 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el)) 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.cg i?id=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:08 --- We really don't want to duplicate the XML files for this. We should be able to generate the old from the new using either an XSLT stylesheet with the Ant style task or with the Ant replace task. - 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 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021.
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=31021
*old* URI for the *.tlds (including for contrib/ (faces el))
--- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:52 ---
Here is a patch that creates 1.1 versions of the tld during the build using
the ant replace task.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-struts/build.xml,v
retrieving revision 1.137
diff -u -r1.137 build.xml
--- build.xml 1 Sep 2004 05:22:28 - 1.137
+++ build.xml 2 Sep 2004 18:46:19 -
@@ -324,6 +324,28 @@
copy todir=${build.home}/library/classes/META-INF/tlds
fileset dir=${build.home}/library includes=struts-*.tld/
/copy
+copy todir=${build.home}/library/classes/META-INF/tlds
overwrite=true
+ fileset dir=${build.home}/library includes=struts-*.tld/
+ mapper type=regexp from=^(.*)\.tld$$ to=\1-1.1.tld/
+/copy
+ replace dir=${build.home}/library/classes/META-INF/tlds
+ include name=*-1.1.tld/
+ replacefilter
+ token=http://struts.apache.org/tags-bean;
+ value=http://jakarta.apache.org/struts/tags-bean/
+ replacefilter
+ token=http://struts.apache.org/tags-html;
+ value=http://jakarta.apache.org/struts/tags-html/
+ replacefilter
+ token=http://struts.apache.org/tags-logic;
+ value=http://jakarta.apache.org/struts/tags-logic/
+ replacefilter
+ token=http://struts.apache.org/tags-nested;
+ value=http://jakarta.apache.org/struts/tags-
nested/
+ replacefilter
+ token=http://struts.apache.org/tags-tiles;
+ value=http://jakarta.apache.org/struts/tags-
tiles/
+ /replace
jar jarfile=${build.home}/library/${app.name}.jar
manifest=${conf.share.dir}/MANIFEST.MF
basedir=${build.home}/library/classes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:53 --- Created an attachment (id=12619) build.xml patch that generates *-1.1.tld version of tlds with legacy uri - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.1 tld uri - RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
I made a patch for this issue and added it to the bug report Matthias created. http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 If this is OK it should be easy to do for struts-el and struts-faces as well. Let me know if you would like patches for those as well. From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thu 9/2/2004 1:04 AM To: Struts Developers List; Craig McClanahan Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp So, do we need changes for the 1.2.3 release? If so, a quick fix/patch would be appreciated. ;-) -- Martin Cooper On Wed, 1 Sep 2004 21:28:13 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Wed, 1 Sep 2004 18:45:22 -0400, Deadman, Hal [EMAIL PROTECTED] wrote: Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: That was exactly my point. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Otherwise, a Struts 1.1 application that relies on the implicit TLD registration done by the container (i.e. *not* listing the TLDs explicitly in web.xml) will go down in flames when run against Struts 1.2.x, unless you go fix the taglib directives in every single page. Basically, it's the same reason that Struts 1.2.x accepts and processes 1.0 and 1.1 versions of struts-config.xml files ... so that older apps can run with minimal changes when you upgrade Struts. It turns out that this doesn't matter for the particular commit message I replied on (which only changed the URI for the struts-faces TLD), but it's an important backwards compatibility principle in general. Craig - 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: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - 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: display collection using logic:iterate
Hi there, If i am not wrong then u have an array of beans(collections) property on formbean from which u get textfeilds values. is this teh case, then plz tell me i will provide u some examples. regards, --- babu [EMAIL PROTECTED] wrote: in struts , i retrieve a collection of data from database and set the data in formbean as a collection . and i try to display the collection in the respective textfields.[ set each value in textfield], for that i used logic:iterate tag and bean:write and html:text tags. but i am not able to display the value in textfield = DIV P align=leftFONT face=Times New RomanBuland Altaf Malik,BRSTRONGSr. Software Engineer/STRONG, BRSoftech System's(pvt)Ltd. BR10/25 asad jan road lahore,cantt - 54810 PakistanBRTel: 92-42-6665812 , 92-42-6660802/FONT/P P align=leftFONT face=Times New RomanMob: 0333-4344113BRFax: 92-42-6665792/FONT/P P align=leftFONT face=Times New RomanA href=http://www.softech.com.pk/;http://www.softech.com.pk/ABRA href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/A/FONT/P/DIV __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - 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: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - 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]
[Apache Struts Wiki] Updated: StrutsTools
Date: 2004-09-02T12:29:58 Editor: MatthiasBurbach [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsTools URL: http://wiki.apache.org/struts/StrutsTools no comment Change Log: -- @@ -9,6 +9,8 @@ http://www.cotsec.com - An Eclipse plugin that generates Struts applications optionally backed by Enterprise Javabeans to the database. Cotsec operates under a quasi-open source model in which the source code is available (like open source), however sales of Cotsec product translates into dollars for Cotsec developers +http://sourceforge.net/projects/flux4eclipse - Flux is a free Java tool available as Eclipse plug-in supporting the model-driven design of a Struts 1.1 web application by repeatedly (re-)generating the struts-config-module.xml files from UML activity diagrams. Extensive documentation is available on the tool's homepage http://flux4eclipse.sourceforge.net + http://otn.oracle.com/products/jdev/index.html - Oracle JDeveloper 10g. Oracle JDeveloper offers an end-to-end J2EE development environment including model based and declaritive editing of Stuts Page Flow, Visual JSP editing and drag and drop databinding into the UI or page flow (based on JSR-227). http://www.m7.com/product.jsp - M7 NitroX for Struts, Eclipse Edition. NitroX was created to comprehensively meet the needs of Java developers building JSP or Struts-based applications. NitroX provides simultaneous source visual JSP and Struts editing with validation and consistency checking throughout all levels of a web application. More info at www.m7.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
You can also look at the whiteboard initially setup by Ted in contrib/struts-jericho/README.txt -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 3:33 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
As far as the struts roadmap for 2.x I would say that it is fairly vague for anyone setting out to develop an initial codebase. It mentions supporting JSF, it talks about portlets, and many other things. But it talks about these things vaguely as if they were 5 years off. I am just saying that if someone is going to begin a 2.x development there should be some serious discussion about what it should look like. I would say a wiki on this would be great. Maybe StrutsNewVersion or something. I don't do much with the wiki, can I just create a new page if I'm registered on it? On Thu, 2 Sep 2004 20:33:15 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31023] New: - Action Grouping
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=31023. 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=31023 Action Grouping Summary: Action Grouping Product: Struts Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A lot of my actions are very similiar. For instance, I may have a create form and an edit form. A lot of times I can reuse the same ActionForm and change the Input(forwards) etc., but at other times, I reuse some but not all of these components. I'd like to see something like: action-group name=... input=... ... forward .../ !-- scope of this group -- action path=/some-path/ !-- leave name and input -- action path=/another-path name=override the default form !-- same input -- forward .../ !-- perhaps override a forward -- /action ... /action-group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Yes -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 3:52 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) As far as the struts roadmap for 2.x I would say that it is fairly vague for anyone setting out to develop an initial codebase. It mentions supporting JSF, it talks about portlets, and many other things. But it talks about these things vaguely as if they were 5 years off. I am just saying that if someone is going to begin a 2.x development there should be some serious discussion about what it should look like. I would say a wiki on this would be great. Maybe StrutsNewVersion or something. I don't do much with the wiki, can I just create a new page if I'm registered on it? On Thu, 2 Sep 2004 20:33:15 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Michael Rasmussen wrote: As far as the struts roadmap for 2.x I would say that it is fairly vague for anyone setting out to develop an initial codebase. Have you not looked at the initial code base of the Struts chain already in CVS? .V It mentions supporting JSF, it talks about portlets, and many other things. But it talks about these things vaguely as if they were 5 years off. I am just saying that if someone is going to begin a 2.x development there should be some serious discussion about what it should look like. I would say a wiki on this would be great. Maybe StrutsNewVersion or something. I don't do much with the wiki, can I just create a new page if I'm registered on it? On Thu, 2 Sep 2004 20:33:15 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. On Thu, 2 Sep 2004 07:02:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 02 Sep 2004 11:43:37 +0200, Anders Steinlein wrote: Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) The best part is that we can have our cake and eat it too :) Those with itches for Servlet 2.4/JSP 2.0/J2SE 5.0 can begin work on Struts 2.x, while others continue to maintain and enhance Struts 1.x. Many projects operate in a mode like this, including Apache HTTPD and Tomcat. We just need someone to step up and say, OK, here's some starter code for Struts 2.x, let's have at it. Meanwhile, those interested in the Struts 1.x base can maintain the status quo. -Ted. - 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] -- Please post on Rich Internet Applications User Interface (RiA/SoA) http://www.portalvu.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
One proposal that's a bit more concrete is Ted's struts-jericho contrib; it contains a proposed DTD which shows how the classes could be organized. Also, there's been some discussion on Struts 2 ideas before: http://marc.theaimsgroup.com/?l=struts-devw=2r=1s=Struts+2.0+Ideas+q=b - Hubert On Thu, 2 Sep 2004 14:52:37 -0500, Michael Rasmussen [EMAIL PROTECTED] wrote: As far as the struts roadmap for 2.x I would say that it is fairly vague for anyone setting out to develop an initial codebase. It mentions supporting JSF, it talks about portlets, and many other things. But it talks about these things vaguely as if they were 5 years off. I am just saying that if someone is going to begin a 2.x development there should be some serious discussion about what it should look like. I would say a wiki on this would be great. Maybe StrutsNewVersion or something. I don't do much with the wiki, can I just create a new page if I'm registered on it? On Thu, 2 Sep 2004 20:33:15 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: Maybe the whiteboard area is good fot this... http://wiki.apache.org/struts/StrutsWhiteboard - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:31 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Struts has a roadmap here: http://struts.apache.org/roadmap.html but maybe it would be easier/better to have something in the wiki, then lots of people could easily contribute Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:12 PM Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Doesn't a struts 2.x codebase need a roadmap first? Should there be some defined goals? Should it implement the same apis as struts 1.x so as to ease transition? Or should it be a whole new framework? Somehow I think the latter would be ill received. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too. I'd been thinking that we'd create the branch, based on the tag, when we decide we need / want it. Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree of revolution will happen in this next (2.3-based) version, as well as some logical evolution. I haven't yet seen any proposed advantages *to Struts future* listed for Servlets 2.4, and my own focus is on getting away from JSP dependencies in the core, so I'm not sure how much the 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. But that's really another thread... -- Martin Cooper -T. - 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: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Mon, 30 Aug 2004 10:14:15 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Mon, 30 Aug 2004 06:09:02 -0400, Ted Husted [EMAIL PROTECTED] wrote: It was once proposed that we leap frog Serlvet 2.3 and go straight to 2.4 for Struts 2.x. But, I continually see references to little things people could do better if our minimum were Servlet 2.3. Since no code has been written for Struts 2.x, it does not seem reasonable to hold back enhancements that we could make today, if our minimum platform were Servlet 2.3. Here's my +1 for moving the minimum platform to Servlet 2.3, today. Carpe Diem! -Ted. +1 to updating the minimum platform for Struts .Next to be Servlet 2.3 (and JSP 1.2), although the technical benefits of going one step further (2.4/2.0) are so compelling I'd be in favor of going there instead: * Servlet filters can run on request dispatcher calls * Cleaned up semantics for internationalized apps How might we want to take advantage of these newer Servlets features in Struts? I've seen a list of why we want to advance to 2.3, but I'm not clear on what 2.4 might do for Struts specifically. (My own requirements are for 2.3, but I'm still interested in what the future might hold. ;) * JSP 2.0 has many new features, including EL everywhere, simple tag apis, tag files, much better XML syntax, ... JSP 2.0 definitely has lots of good stuff in it. However, my feeling is that we want to avoid, or at least isolate, JSP dependencies in the Struts core. So in that sense, JSP 2.0 doesn't really matter to us very much. -- Martin Cooper The counterbalance, of course, is the smaller number of deployed containers supporting these APIs -- but that couterbalance gets smaller over time, and I suspect will be non-existent by the time we could get to a complete enough release to be GA quality. I also suspect, given our track record :-), that re-engineering Struts from scratch based on the latest platform APIs wouldn't take more time than a gradual refactoring from the current code. Regarding branches, STRUTS_1_2_BRANCH should definitely be created if it's not yet, for ongoing development on that track, so the head can be used for new development. And, since we'll contemplate non-backwards-compatible changes anyway, let's just call it Struts 2 and be done with it. Craig On Sun, 29 Aug 2004 10:47:01 -0700, Martin Cooper wrote: I would be very much in favour of breaking out the multipart handling properties into their own section. However, I don't really want to do this now. I'd prefer to wait until we rip out the multipart code into a filter, rationalise the interface, and better align the implementation with Commons FileUpload. With that set of changes, the specific parameters will likely change, so I'd prefer to change everything at once. (This is one of my own itches that has needed to wait for a Struts 2.x or higher, because of the Servlets 2.3 requirement. ;) On Sun, 29 Aug 2004 20:22:57 -0500, Joe Germuska wrote: 29668 is basically a statement of the problem I am facing. I guess I should have looked through bugzilla. It looks as though 29824 proposes using setCharacterEncoding, so I don't think it would compile with Servlet 2.2. (I haven't tried it yet.) - 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 31025] New: - validwhenparser null pointer exception
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=31025. 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=31025 validwhenparser null pointer exception Summary: validwhenparser null pointer exception Product: Struts Version: 1.1 Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31026] New: - validwhen bugs
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=31026. 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=31026 validwhen bugs Summary: validwhen bugs Product: Struts Version: 1.1 Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - for an int field, cannot parse number 0 when (*this* != 0) I get message char '0' is invalid. - for a String field, cannot parse (*this* != '--') I get message '-' is an invalid character - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Ironic as it seems to myself to be saying it, I don't think I like the idea of Struts moving to newer spec/JDK versions just yet. Here at work, most of our development is now Struts-based, and much of it is moving to IBM Portal Server. Unfortunately, because of some issues between that product and WebSphere itself (and probably some other components), we are currently very sensitive to versioning, more so than we might otherwise be. For instance, I have a production app that is based on Struts 1.1, and I have it running on a rogue Tomcat server with JDK 1.3.1 because IBM is not yet supporting a higher JDK version, believe it or not! If the newest Struts has a bunch of cool features, but it requires a higher JDK or higher servlet specs than Tomcat or Websphere (when we finally figure out how to get the app up on it), I'm going to be in a bind with this app because I'm sure to want to use those features (and being able to make some good business cases for doing so even) but not be able to. If nothing else, that's going to be depressing :) The flip-side of the argument of course is that eventually everyone is going to want, and be able, to move to all the newest specs, JDK levels, etc., me along with them. And of course the difficult decision is when to make that move. My point in the end I think is that if you can scratch the itches without *requiring* newer versions of anything, I think that would be ideal. For those things that absolutely can't be done without newer versions, I'd like to see those new features optional or swappable in some way. Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies www.omnytex.com From: Anders Steinlein [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Date: Thu, 2 Sep 2004 11:43:37 +0200 It's more than a thought ... I was about three keystrokes from including this in my proposal to be forward looking on servlet 2.4 and JSP 2.0 :-). I'd love to see Servlet2.4 and JSP2.0 be the minimum. It was mentioned before that several of the 'itches' that the committers have revolve around more recent versions of the specs. I would think that this logic could also be applied to potential contributors who have been sitting on the sidelines waiting to figure out how to get involved. Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27439] - Form definition inheritance support
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=27439. 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=27439 Form definition inheritance support --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 23:13 --- This looks like the same as Bug 22600 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Can you keep using 1.2.3? .V Frank Zammetti wrote: Ironic as it seems to myself to be saying it, I don't think I like the idea of Struts moving to newer spec/JDK versions just yet. Here at work, most of our development is now Struts-based, and much of it is moving to IBM Portal Server. Unfortunately, because of some issues between that product and WebSphere itself (and probably some other components), we are currently very sensitive to versioning, more so than we might otherwise be. For instance, I have a production app that is based on Struts 1.1, and I have it running on a rogue Tomcat server with JDK 1.3.1 because IBM is not yet supporting a higher JDK version, believe it or not! If the newest Struts has a bunch of cool features, but it requires a higher JDK or higher servlet specs than Tomcat or Websphere (when we finally figure out how to get the app up on it), I'm going to be in a bind with this app because I'm sure to want to use those features (and being able to make some good business cases for doing so even) but not be able to. If nothing else, that's going to be depressing :) The flip-side of the argument of course is that eventually everyone is going to want, and be able, to move to all the newest specs, JDK levels, etc., me along with them. And of course the difficult decision is when to make that move. My point in the end I think is that if you can scratch the itches without *requiring* newer versions of anything, I think that would be ideal. For those things that absolutely can't be done without newer versions, I'd like to see those new features optional or swappable in some way. Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies www.omnytex.com From: Anders Steinlein [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?) Date: Thu, 2 Sep 2004 11:43:37 +0200 It's more than a thought ... I was about three keystrokes from including this in my proposal to be forward looking on servlet 2.4 and JSP 2.0 :-). I'd love to see Servlet2.4 and JSP2.0 be the minimum. It was mentioned before that several of the 'itches' that the committers have revolve around more recent versions of the specs. I would think that this logic could also be applied to potential contributors who have been sitting on the sidelines waiting to figure out how to get involved. Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a revolution-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx -- Please post on Rich Internet Applications User Interface (RiA/SoA) http://www.portalvu.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Thu, 02 Sep 2004 13:50:30 -0700, Martin Cooper wrote: Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree of revolution will happen in this next (2.3-based) version, as well as some logical evolution. I haven't yet seen any proposed advantages *to Struts future* listed for Servlets 2.4, and my own focus is on getting away from JSP dependencies in the core, so I'm not sure how much the 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. But that's really another thread... I'd say 1.3.x. Moving the minimum platform is worth rolling the minor version number, but there are not any API changes on the table. When and if something revolutionary happens, we can always roll the major version number then. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31023] - Action Grouping
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=31023. 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=31023 Action Grouping --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 23:41 --- Something thats been discussed is the idea of having inheritance in the struts- config, which I think achieves the same goal as what you're proposing. I don't think theres a bug that covers struts-config inheritance - Bug 22600 deals with form bean inheritance, but nothing else. If we were to adopt a similar approach to Tiles, using an extends attribute, adding that to the form-bean, forward and action-mapping elements. So for example form-beans form-bean name=FormA type=someDynaFormFlavour form-property name=property_1 type=java.lang.String/ form-property name=property_2 type=java.lang.String/ /form-bean form-bean name=FormB extends=FormA form-property name=property_2 type=java.lang.Integer/ form-property name=property_3 type=java.lang.String/ /form-bean /form-beans global-forwards forward name=default className=myPackage.MyForwardConfig redirect=false path=// forward name=myModuleB extends=default module=myModuleB path=/myModuleB/ /global-forwards action-mappings action path=/initialPathA type=myPackage.ActionA name=FormA scope=request validate=false forward name=success extends=default path=/Abc.jsp/ /action action path=/submitPathA extends=/initialPathA validate=true input=/Abc.jsp forward name=switch extends=myModuleB path=/Def.jsp/ /action /action-mappings Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts build.xml
niallp 2004/09/02 17:30:55
Modified:.build.xml
Log:
Bug 31021 Create legacy tlds with jakarta URI - patch suppiled by Hal Deadman
Revision ChangesPath
1.138 +9 -0 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- build.xml 1 Sep 2004 05:22:28 - 1.137
+++ build.xml 3 Sep 2004 00:30:55 - 1.138
@@ -324,6 +324,15 @@
copy todir=${build.home}/library/classes/META-INF/tlds
fileset dir=${build.home}/library includes=struts-*.tld/
/copy
+copy todir=${build.home}/library/classes/META-INF/tlds overwrite=true
+fileset dir=${build.home}/library includes=struts-*.tld/
+mapper type=regexp from=^(.*)\.tld$$ to=\1-1.1.tld/
+/copy
+replace dir=${build.home}/library/classes/META-INF/tlds
+include name=*-1.1.tld/
+replacefilter token=http://struts.apache.org/tags;
+ value=http://jakarta.apache.org/struts/tags/
+/replace
jar jarfile=${build.home}/library/${app.name}.jar
manifest=${conf.share.dir}/MANIFEST.MF
basedir=${build.home}/library/classes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el build.xml
niallp 2004/09/02 18:33:17
Modified:contrib/struts-el build.xml
Log:
Bug 31021 Create legacy tlds with jakarta URI - patch suppiled by Hal Deadman
Revision ChangesPath
1.23 +10 -1 jakarta-struts/contrib/struts-el/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- build.xml 29 Feb 2004 22:55:45 - 1.22
+++ build.xml 3 Sep 2004 01:33:17 - 1.23
@@ -242,8 +242,17 @@
extension=.tld style=${doc.dir}/stylesheets/tld.xsl
includes=struts-*.xml/
copy todir=${build.home}/library/classes/META-INF/tlds
- fileset dir=${build.home}/library includes=struts-*.tld/
+ fileset dir=${build.home}/library includes=struts-*-el.tld/
/copy
+ copy todir=${build.home}/library/classes/META-INF/tlds overwrite=true
+ fileset dir=${build.home}/library includes=struts-*-el.tld/
+ mapper type=regexp from=^(.*)\.tld$$ to=\1-1.1.tld/
+ /copy
+ replace dir=${build.home}/library/classes/META-INF/tlds
+ include name=*-1.1.tld/
+ replacefilter token=http://struts.apache.org/tags;
+ value=http://jakarta.apache.org/struts/tags/
+ /replace
jar jarfile=${build.home}/library/${app.name}.jar
basedir=${build.home}/library/classes includes=**/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30884] - ActionForward constructor for copying existing AFs skip the module property
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=30884. 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=30884 ActionForward constructor for copying existing AFs skip the module property [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 02:49 --- Thanks for the patch Hubert, I've applied it. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
niallp 2004/09/02 19:48:50
Modified:src/share/org/apache/struts/action ActionServlet.java
Log:
Bug 30707 fix ActionServlet bottleneck based on patch supplied by Kris Jenkins
Revision ChangesPath
1.178 +12 -5
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
Index: ActionServlet.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
retrieving revision 1.177
retrieving revision 1.178
diff -u -r1.177 -r1.178
--- ActionServlet.java9 Jun 2004 00:25:15 - 1.177
+++ ActionServlet.java3 Sep 2004 02:48:50 - 1.178
@@ -1155,7 +1155,14 @@
throws IOException, ServletException {
ModuleUtils.getInstance().selectModule(request, getServletContext());
-getRequestProcessor(getModuleConfig(request)).process(request, response);
+ModuleConfig config = getModuleConfig(request);
+
+RequestProcessor processor = getProcessorForModule(config);
+if (processor == null) {
+ processor = getRequestProcessor(config);
+}
+processor.process(request, response);
+
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30707] - Bottleneck in ActionServlet
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=30707. 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=30707 Bottleneck in ActionServlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 02:56 --- Kris, Thanks for the patch. I implemented it slightly differently, using the existing methods. All the changes are in the process(HttpServletRequest, HttpServletResponse) method in ActionServlet: http://cvs.apache.org/viewcvs.cgi/jakarta- struts/src/share/org/apache/struts/action/ I've tested the new version, but if you could try out the performance it would be much appreciated. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsRelease123
Date: 2004-09-02T20:07:18 Editor: NiallPemberton [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsRelease123 URL: http://wiki.apache.org/struts/StrutsRelease123 no comment Change Log: -- @@ -20,13 +20,17 @@ || '''ID''' || '''Summary''' || '''Component''' || '''Prevents Release''' || ||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30696 30696]||Struts-Tiles-JSF-Integration SOMETIMES creates blank pages|| Struts-Faces||No|| -||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30707 30707]||Bottleneck in ActionServlet||Standard Actions|| No (Later) || -||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30717 30717]||MessageResources.java has unsynchronized access to MessageFo||Utilities|| No || +||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30707 30707]||Bottleneck in ActionServlet||Standard Actions|| No (FIXED) || +||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30717 30717]||MessageResources.java has unsynchronized access to MessageFo||Utilities|| No (WONTFIX)|| ||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30842 30842]||html:link not using page charset encoding (defaults to UT || Custom Tags|| No (Resolved)|| ||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30876 30876]||While using File Upload, getting ClassCastException when returning from a FormBean/Action Class|| File Upload||No (Unconfirmed)|| -||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30884 30884]||ActionForward constructor for copying existing AFs skip the module property||Controller||No (Later)|| +||[http://issues.apache.org/bugzilla/show_bug.cgi?id=30884 30884]||ActionForward constructor for copying existing AFs skip the module property||Controller||No (FIXED)|| +||[http://issues.apache.org/bugzilla/show_bug.cgi?id=31025 31025]||validwhenparser null pointer exception ||Validator||_|| +||[http://issues.apache.org/bugzilla/show_bug.cgi?id=31026 31026]||validwhen bugs||Validator||_|| (craigmcc: Note that the struts-faces bugs are not directly relevant to a Struts 1.2.2 release because this library is not included.) + +(niallp: I have applied patches for bugs [http://issues.apache.org/bugzilla/show_bug.cgi?id=30707 30707] and [http://issues.apache.org/bugzilla/show_bug.cgi?id=30884 30884] as it seems like a shame to release with these in. They were marked as later but if anyone objects we could release without them) == Preparation Checklist == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/examples/WEB-INF/validator validation.xml
niallp 2004/09/02 21:38:57 Modified:web/blank/WEB-INF validation.xml web/example/WEB-INF validation.xml web/examples/WEB-INF/validator validation.xml Log: Change to use new dtd for Validator 1.1.3 Revision ChangesPath 1.6 +2 -2 jakarta-struts/web/blank/WEB-INF/validation.xml Index: validation.xml === RCS file: /home/cvs/jakarta-struts/web/blank/WEB-INF/validation.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- validation.xml25 Jun 2004 00:56:13 - 1.5 +++ validation.xml3 Sep 2004 04:38:56 - 1.6 @@ -1,8 +1,8 @@ ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE form-validation PUBLIC - -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN - http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; + -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN + http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd; form-validation 1.15 +3 -3 jakarta-struts/web/example/WEB-INF/validation.xml Index: validation.xml === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/validation.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- validation.xml25 Jun 2004 00:56:13 - 1.14 +++ validation.xml3 Sep 2004 04:38:57 - 1.15 @@ -1,8 +1,8 @@ ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE form-validation PUBLIC - -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN - http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; + -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN + http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd; !-- Validation Rules for the Struts Example Web Application 1.5 +3 -1 jakarta-struts/web/examples/WEB-INF/validator/validation.xml Index: validation.xml === RCS file: /home/cvs/jakarta-struts/web/examples/WEB-INF/validator/validation.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- validation.xml25 Jun 2004 00:56:13 - 1.4 +++ validation.xml3 Sep 2004 04:38:57 - 1.5 @@ -1,5 +1,7 @@ ?xml version=1.0 encoding=iso-8859-1? -!DOCTYPE form-validation SYSTEM http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; +!DOCTYPE form-validation PUBLIC + -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN + http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd; form-validation global constant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too. I'd been thinking that we'd create the branch, based on the tag, when we decide we need / want it. Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree of revolution will happen in this next (2.3-based) version, as well as some logical evolution. I haven't yet seen any proposed advantages *to Struts future* listed for Servlets 2.4, and my own focus is on getting away from JSP dependencies in the core, so I'm not sure how much the 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. But that's really another thread... I gathered that the conclusion for the evolution branch (which, IMHO, should be called 1.3 if it's going to focus on things like the chain version of RequestProcessor but remain fundamentally backwards compatible). FWIW, here are some specific technical benefits (for the framework architecture, for applications based on it, or both) if we were to choose Servlet 2.4 over Servlet 2.3: * HttpServletRequest.setCharacterEncoding() allows applications to resolve nearly all the ambiguities of parsing request parameters in the right encoding (which is a smaller number of problems than it used to be in 2.4 generally, because the rules have been tightened, and because of the next feature). * You can define (in web.xml) your own mapping table from locale to character encoding, rather than relying on the container's undocumented (and likely non-portable) defaults. * Filters can be declared to run on RequestDispatcher.forward() calls as well as on the original request. Without this, it's basically impossible to write use-case-specific Filters in an MVC framework that uses RD.forward() the way Struts does today. * ServletRequestListener fleshes out the lifecycle model, so you can do things like adding some resource to the request attributes, and knowing that it will get cleaned up (after the response has been rendered by the JSP page or whatever) by your listener. * ServletRequestAttributeListener can listen to changes on your request attributes, similar to how HttpSessionAttributeListener and ServletContextAttributeListener work in 2.3. * On an HttpSessionBindingListener, the listener is invoked when you actually expect it to be at session end (*before* the session is invalidated, rather than after). * Welcome Files can now be servlets, so you can use index.do instead of having an index.jsp that forwards to an action that does your setup. * Deployment descriptors (web.xml) that conform to the 2.4 schema can have their elements listed in any order, instead of the pretty arbitrary sequence required by 2.3. The benefits of JSP 2.0 over 1.2 are even more compelling, but have been discussed before. My favorite three favorite features are EL everywhere, tag files (a way to create simple UI components with just JSP code), and the simple tag API. Counterbalancing all of this, of course, is the question of installed base. And, of course, that is a question that has a different answer at different times. If we want to work towards a GA quality 1.3 release in 3-6 months (possible if the set of changes is limited), than staying with 2.3/1.2 makes a lot of sense. But if it takes us the more typical 12-18 months, where do *you* think the world is going to be by then? NOTE: None of this is to suggest that maintenance activities on 1.2.x should not continue. However, it should, IMHO, be focused on bug fixes rather than feature enhancements, and should (of course) remain based on Servlet 2.2 / JSP 1.1. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Thu, 02 Sep 2004 19:06:44 -0400, Frank Zammetti [EMAIL PROTECTED] wrote: Ironic as it seems to myself to be saying it, I don't think I like the idea of Struts moving to newer spec/JDK versions just yet. Here at work, most of our development is now Struts-based, and much of it is moving to IBM Portal Server. Unfortunately, because of some issues between that product and WebSphere itself (and probably some other components), we are currently very sensitive to versioning, more so than we might otherwise be. Ironically, people wanting to run Struts in a portlet (JSR-168 compatible) environment should be the ones most interested in a Struts revolution :-). The current method signatures for all the important methods are very much dependent on the servlet APIs, and the various portal server vendors have all done their own (non-interoperable) modifications to Struts to make it kind-of sort-of work. We should be doing that. We can't do that based on Servlet 2.2 / JSP 1.1. Craig For instance, I have a production app that is based on Struts 1.1, and I have it running on a rogue Tomcat server with JDK 1.3.1 because IBM is not yet supporting a higher JDK version, believe it or not! If the newest Struts has a bunch of cool features, but it requires a higher JDK or higher servlet specs than Tomcat or Websphere (when we finally figure out how to get the app up on it), I'm going to be in a bind with this app because I'm sure to want to use those features (and being able to make some good business cases for doing so even) but not be able to. If nothing else, that's going to be depressing :) The flip-side of the argument of course is that eventually everyone is going to want, and be able, to move to all the newest specs, JDK levels, etc., me along with them. And of course the difficult decision is when to make that move. My point in the end I think is that if you can scratch the itches without *requiring* newer versions of anything, I think that would be ideal. For those things that absolutely can't be done without newer versions, I'd like to see those new features optional or swappable in some way. I don't believe it is possible to scratch the itches without *requiring* newer versions of anything. Choosing a newer version of servlet or JSP apis is buying in to the ability to do the fundamental architecture of Struts in a new and different way. That's not the kind of thing you do with optional add on packages that have extra requirements. Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies www.omnytex.com Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Fri, 3 Sep 2004 01:10:43 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: I agree with what Vic said in this thread on the Servlet Spec issue - if we can take the Servlet version out of the equation so that any version can be plugged in to the core controller than that would be really good. We have that already, right? Struts runs on Servlet 2.2 / 2.3 / 2.4 platforms today. What you can't do is a fundamental redesign of a controller architecture that depends on 2.4 features and craft it in such a way that it's an optional add-on feature that can be plugged in on top of 2.2 or 2.3. Adding something like filters that work on a RequestDispatcher call cannot be added at the application level -- they have to be done by the container. Unless, of course, you plan on re-inventing what RequestDispatcher and Filter do ... but that seems like a monumental waste of time. The JDK thing is a different issue though - it could be developed with compatibility to existing JDK versions and keep everyone happy. I have no technical reasons, but I would like to go to JDK 1.5 simply for the reason that it scratches my itch to play with the latest stuff and hopefully produce simpler, cleaner code with the new features it provides. Standard JDK 5.0 annotations cannot be used (inside of Struts) if you want to work on prior JDKs. Neither can generics. Or autoboxing. Or (insert-your-favorite-new-feature-here) ... Without all of that, what's the point again? :-) Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
On 3 Sep 2004 01:38:30 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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=31021. 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=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 01:38 --- Hal, Thanks for the patch - I've applied it with a slight modification and I've also changed the struts-el build script to do the same. Awesome job Hal! Craig indicated on the dev list that this wasn't required for the struts faces tld (probably because it hasn't been *released*) so I'm closing this bug. I'll add a note to the README.txt for struts-faces though. Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-faces README.txt
craigmcc2004/09/02 22:13:57 Modified:contrib/struts-faces README.txt Log: Add a note about the fact that the tag library URI has changed, in response to the fact that Struts is now a top level project. Revision ChangesPath 1.17 +11 -2 jakarta-struts/contrib/struts-faces/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-faces/README.txt,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- README.txt21 Aug 2004 18:25:10 - 1.16 +++ README.txt3 Sep 2004 05:13:57 - 1.17 @@ -33,6 +33,15 @@ This release of the Struts-Faces Integration Library (Version 1.0) has the following new features relative to the previous (0.4) release: +* As of the nightly build 20040902, the URI for the struts-faces tag library + has changed. You should now be using: + +%@ taglib prefix=s uri=http://struts.apache.org/tags-faces; % + + instead of: + +%@ taglib prefix=s uri=http://jakarta.apache.org/struts/tags-faces; % + * It is now possible to mix pure JavaServer Faces pages, and those using the struts-faces integration library, in the same webapp. Previously, it was required to use only Struts-based handlers for form submits. @@ -400,7 +409,7 @@ %@ taglib prefix=c uri=http://java.sun.com/jstl/core; % %@ taglib prefix=f uri=http://java.sun.com/jsf/core; % %@ taglib prefix=h uri=http://java.sun.com/jsf/html; % -%@ taglib prefix=s uri=http://jakarta.apache.org/struts/tags-faces; % +%@ taglib prefix=s uri=http://struts.apache.org/tags-faces; % - The Struts-Faces tag library (prefix s above) contains replacements for functionality in the existing Struts HTML tag library that are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Thu, 2 Sep 2004 21:49:17 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too. I'd been thinking that we'd create the branch, based on the tag, when we decide we need / want it. Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree of revolution will happen in this next (2.3-based) version, as well as some logical evolution. I haven't yet seen any proposed advantages *to Struts future* listed for Servlets 2.4, and my own focus is on getting away from JSP dependencies in the core, so I'm not sure how much the 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. But that's really another thread... I gathered that the conclusion for the evolution branch (which, IMHO, should be called 1.3 if it's going to focus on things like the chain version of RequestProcessor but remain fundamentally backwards compatible). The conclusion was... I think you didn't quite finish the sentence. ;-) One example of a concrete set of changes that I want to make in a Servlets 2.3 compliant next version of Struts will involve the use of a filter for file uploads, as well as significant changes to the interfaces involved. These are interfaces that are exposed as hooks today, so this would certainly break backwards compatibility. That makes it questionable, in my mind, as to whether we should make such changes in a dot release. And then there's the question of changing the core Servlets dependency in a dot release. Some time ago, we decided that we couldn't do that in a dot release, and needed to wait for a major version hike. We're allowed to change our minds, of course, but I just wanted to remind folks of what we had agreed on a while ago. ;-) If calling a next release 1.3 means we get to upgrade the dependency to 2.3, but have to remain backwards compatible in all other respects, then I think that would be unnecessarily limiting, and would suggest that we call it 2.0 instead. Of course, it's conceivable that we have a 2.0 based on Servlets 2.3 and a 3.0 based on Servlets 2.4 in development at the same time (a la Tomcat from a couple of years ago), but I think this would be unfortunate, especially if both groups were changing interfaces in different ways. FWIW, here are some specific technical benefits (for the framework architecture, for applications based on it, or both) if we were to choose Servlet 2.4 over Servlet 2.3: * HttpServletRequest.setCharacterEncoding() allows applications to resolve nearly all the ambiguities of parsing request parameters in the right encoding (which is a smaller number of problems than it used to be in 2.4 generally, because the rules have been tightened, and because of the next feature). * You can define (in web.xml) your own mapping table from locale to character encoding, rather than relying on the container's undocumented (and likely non-portable) defaults. * Filters can be declared to run on RequestDispatcher.forward() calls as well as on the original request. Without this, it's basically impossible to write use-case-specific Filters in an MVC framework that uses RD.forward() the way Struts does today. * ServletRequestListener fleshes out the lifecycle model, so you can do things like adding some resource to the request attributes, and knowing that it will get cleaned up (after the response has been rendered by the JSP page or whatever) by your listener. * ServletRequestAttributeListener can listen to changes on your request attributes, similar to how HttpSessionAttributeListener and ServletContextAttributeListener work in 2.3. * On an HttpSessionBindingListener, the listener is invoked when you actually expect it to be at session end (*before* the session is invalidated, rather than after). * Welcome Files can now be servlets, so you can use index.do instead of having an index.jsp that forwards to an action that does your setup. * Deployment descriptors (web.xml) that conform to the 2.4 schema can have their elements listed in any order, instead of the pretty arbitrary sequence required by 2.3. These are all nice things to have, and would no doubt help clean some things up somewhat and fix some issues in people's Struts apps. But what I was really trying to ask was: What new Struts features do people have in mind that would *require* the use of Servlets 2.4 to accomplish? The
