DO NOT REPLY [Bug 30204] New: - README not up-to-date for deployement of included WAR files
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=30204. 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=30204 README not up-to-date for deployement of included WAR files Summary: README not up-to-date for deployement of included WAR files Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] README says the WAR files are in lib but they are in webapps : struts-documentation.war struts-example.war and maybe others are concerned - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote: (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) I think the decision would have to depend on who is going to maintain the glue. A case in point is the VelTools. There's some Struts glue that is currently being maintained there. I encouraged that since the people interested in the glue were members of the Velocity community. A volunteer shouldn't have to follow a DEV list to maintain code, they should maintain code because they are following a DEV list. :) Of course, that's changed a bit now, and we have VelStrutsTools people who hang out here now, so today it could go either way. In a volunteer organization, some decisions may seem arbitrary, since the volunteers can be arbitrary, and decisions without volunteers don't exist. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 21:07:14 -0700, Martin Cooper wrote: One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel? How about this: * On the roadmap, we reclassify Struts 1.3+ as Struts 2.0, and what-was 2.0 as 3.0. * We clear the 1.2.1 problem tickets, issue the 1.2.2 release, and vote whether it is GA or not. * We link the Acquiring page to the mirroring system. * We have infrastructure import the jakarta-struts CVS to an apache-struts SVN, but we put it all under a /v1 directory. * We continue the work we started in the private SVN under a /v2 directory in the apache-struts SVN. So, the top-level of struts-apache would look like /v1 /v2 /v3 And the branch Craig started for the core subproject would live under /v2/trunk/core And the 1.2.2 release would be at /v1/trunk/ If we needed to make any further releases in the 1.2.x series, we could do those from there. But let's ship a GA 1.2.2 first. Thoughts? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30188] - FileUpload does not work with i18n filenames.
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=30188. 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=30188 FileUpload does not work with i18n filenames. --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 13:33 --- Can you please document this asap or point me to any place which has an example of the solution mentioned. I would greatly appriciate that. Thanks Srini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
Does this include having Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3, and 2.4 respectively? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:15 PM Subject: Re: Repository Reorg (Once More With Feeling) On Mon, 19 Jul 2004 21:07:14 -0700, Martin Cooper wrote: One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel? How about this: * On the roadmap, we reclassify Struts 1.3+ as Struts 2.0, and what-was 2.0 as 3.0. * We clear the 1.2.1 problem tickets, issue the 1.2.2 release, and vote whether it is GA or not. * We link the Acquiring page to the mirroring system. * We have infrastructure import the jakarta-struts CVS to an apache-struts SVN, but we put it all under a /v1 directory. * We continue the work we started in the private SVN under a /v2 directory in the apache-struts SVN. So, the top-level of struts-apache would look like /v1 /v2 /v3 And the branch Craig started for the core subproject would live under /v2/trunk/core And the 1.2.2 release would be at /v1/trunk/ If we needed to make any further releases in the 1.2.x series, we could do those from there. But let's ship a GA 1.2.2 first. Thoughts? -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: Repository Reorg (Once More With Feeling)
On Tue, 20 Jul 2004 06:53:04 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote: (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) I think the decision would have to depend on who is going to maintain the glue. A case in point is the VelTools. There's some Struts glue that is currently being maintained there. I encouraged that since the people interested in the glue were members of the Velocity community. A volunteer shouldn't have to follow a DEV list to maintain code, they should maintain code because they are following a DEV list. :) Of course, that's changed a bit now, and we have VelStrutsTools people who hang out here now, so today it could go either way. We have precedents for dealing with this that seem to work fine: * File upload -- generic code in separate (Commons) package; glue in Struts * Chain integration -- same thing If the Tiles folks want to create a Struts-free distribution, two separate modules (generic and glue) are certainly possible. And, as far as I'm concerned, the generic one is welcome to stay here. In a volunteer organization, some decisions may seem arbitrary, since the volunteers can be arbitrary, and decisions without volunteers don't exist. :) -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30210] New: - Multipart forms processed in reset() method
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=30210. 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=30210 Multipart forms processed in reset() method Summary: Multipart forms processed in reset() method Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a form is of type multipart, it's not possible to get the request parameters calling request.getParameter(param_name) because multipart forms are processed later, in the RequestUtils.populate() method. Sometimes can be useful to get parameters in the reset() method, for example, to set the value of the checkboxes in a multipage form. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: RequestProcessor
Date: 2004-07-20T08:04:19
Editor: JamesChilders [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: RequestProcessor
URL: http://wiki.apache.org/struts/RequestProcessor
no comment
Change Log:
--
@@ -1,3 +1,27 @@
+Package: org.apache.struts.action
+
+RequestProcessor contains the processing logic that the Struts controller servlet
performs as it receives each servlet request from the container. You can customize
the request processing behavior by subclassing this class and overriding the method(s)
whose behavior you are interested in changing.
+
+A simple example of a custom RequestProcessor is:
+
+{{{
+package com.yourco.action;
+
+public class WebcoreRequestProcessor extends RequestProcessor {
+System.out.println( Before processForwardConfig method.);
+}
+}}}
+
+Which would be defined in StrutsConfigXml thus:
+
+{{{
+controller processorClass=com.yourco.action.YourCoRequestProcessor /
+}}}
+
+See the [http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd
struts-config.xml DTD] for the complete list of attributes accepted by the controller
element.
+
+
+
Has anyone considered a mechanism to make a composite RequestProcessor? It seems
like the biggest obstacle is the struts-config DTD. I think you could get there by
extending ControllerConfig and setting properties on it, and making sure that your
ControllerConfig and your RequestProcessor could see each other.
This would be an awesome feature. Currently we are looking to incorporate three
different RequestProcessors
(TilesRequestProcessor,BC4JRequestProcessor,WorkflowRequestProcessor) and the only
solution is to take all the sources and modify them into one RequestProcessor. It
would be great if I could add them all together without modifying the third-party
source code.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: RequestProcessor
Date: 2004-07-20T08:06:19
Editor: JamesChilders [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: RequestProcessor
URL: http://wiki.apache.org/struts/RequestProcessor
no comment
Change Log:
--
@@ -7,8 +7,11 @@
{{{
package com.yourco.action;
-public class WebcoreRequestProcessor extends RequestProcessor {
-System.out.println( Before processForwardConfig method.);
+public class YourCoRequestProcessor extends RequestProcessor {
+protected void processForwardConfig(HttpServletRequest request,
HttpServletResponse response, ForwardConfig forward) throws IOException,
ServletException {
+System.out.println(In processForwardConfig() method.);
+super.processForwardConfig(request, response, forward);
+}
}
}}}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29848] - Return appropriate status code when form validation fails
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=29848.
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=29848
Return appropriate status code when form validation fails
--- Additional Comments From [EMAIL PROTECTED] 2004-07-20 15:28 ---
Possible solution: In the RequestProcessor processValidate method, right after
if ((errors == null) || errors.isEmpty()) {
...
return (true);
}
add
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: PoweredBy
Date: 2004-07-20T11:39:22 Editor: JamesChilders [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: PoweredBy URL: http://wiki.apache.org/struts/PoweredBy no comment Change Log: -- @@ -4,3 +4,4 @@ * [http://www.agileedge.com Agility Bug Tracker] * [http://telemetry.logica.co.uk] Master Control - telemetry on the web, produced by LogicaCMG built on Tomcat. * [http://openmozart.net] + * [http://www.hotels.com] - Several parts of hotels.com use Struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
