[Struts Wiki] Update of StrutsActionRelease134 by TedHusted
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by TedHusted: http://wiki.apache.org/struts/StrutsActionRelease134 The comment on the change is: Flesh-out major features section -- http://struts.apache.org/download.cgi - [Highlight new features?] + Major changes since Struts Action 1.2 include + + * Composable Request Processor + * Arbitrary configuration properties + * Opt-In Cancel Handling + * Enhanced Global Exception Handlers + * Extends attribute + * isCommitted Exception Handling + * Postback Actions + * Wildcard ActionConfig properties + + Composable Request Processor: For Action 1.3, we turned the request processor methods into Commands that are part of a flexible Chain of Commands. + + Arbitrary configuration properties: Most every Struts configuration element now accepts a map of key/value pairs. Arbitrary configuration properties let us externalize more of our configurations, encouraging reuse. + + Opt-In Cancel Handling: In Struts Action 1.3, the Cancel token is only honored if the new property cancellable is set for the Action Mapping. If the Cancel token is present, but cancellable is not set, then an InvalidCancelException is thrown. The InvalidCancelExeption may be caught by a Declarative Exception Handler, like any other Exception. + + Enhanced Global Exception Handlers: We now support use of global exception handlers in cases when no ActionConfig has yet been identified, as in with preprocessing commands in a custom request processing chain. + + Extends attribute: In the Struts configuration file, we can now use the extends attribute to adopt default settings from another element, as we already can in the Tiles configuration files. + + isCommitted Exception Handling: When using Tiles, sometimes the response is already committed when an exception occurs. Now, the ExceptionHandler tests response.isCommitted , and, if true, includes the configured view path, rather than forwarding to it. + + Postback Forms: The action attribute of the Form taglib is now optional. If omitted, the original URI of the original request is used. + + Wildcard ActionConfig properties: Wildcards can now be used in the properties of an ActionConfig. + + The 1.3.x series of Struts Action Framework has a minumum requirement of the following specification versions: + + * Java Servlet 2.3 and JavaServer Pages (JSP) 1.2 + * Java 2 Standard Platform Edition (J2SE) 1.4 The release notes are available online at: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsUpgradeNotes12to13 by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsUpgradeNotes12to13
The comment on the change is:
Reorganize the configuration section.
--
== 4. Configuration ==
+ === 4.1 CoR Request Processor ===
+
The ''default'' Request Processor for Struts 1.3 is the new Chain (CoR) based
''ComposableRequestProcessor''.
- === 4.1 CoR Request Processor ===
By default, the ComposableRequestProcessor will use a configuration file
included in the struts-core JAR, and you won't need to do anything.
+ === 4.2 Original Request Processors ===
+
+ If you want to continue using either of the existing Request Processors (i.e.
RequestProcessor or TilesRequestProcessor) then you need to specify this in the
controller element of the ''struts-config.xml''
+
+ {{{
+ controller processorClass=org.apache.struts.action.RequestProcessor /
+ }}}
+
+ {{{
+ controller
processorClass=org.apache.struts.tiles.TilesRequestProcessor /
+ }}}
+
+ === 4.3 Tiles ===
+
- However, if you want to use Tiles, you must instruct Struts to use a
configuration file included in the struts-tiles JAR instead. To do this:
+ If you want to use Tiles, you must instruct Struts to use a configuration
file included in the struts-tiles JAR instead. To do this:
* Add a '''chainConfig''' ''init-param'' in the web.xml pointing to the
location of the ''chain-config.xml''
@@ -71, +86 @@
/init-param
}}}
+ In addition to configuring the ComposableRequestProcessor to use the provided
Tiles chain config file, you should also update the '''DOCTYPE''' definition in
your ''tiles-defs.xml'' file:
- You can do much more to configure the ComposableRequestProcessor, but those
details are outside the scope of this document.
-
- === 4.2 Original Request Processors ===
-
- If you want to continue using either of the existing Request Processors (i.e.
RequestProcessor or TilesRequestProcessor) then you need to specify this in the
controller element of the ''struts-config.xml''
{{{
- controller
processorClass=org.apache.struts.tiles.TilesRequestProcessor /
+!DOCTYPE tiles-definitions PUBLIC
+ -//Apache Software Foundation//DTD Tiles Configuration 1.3//EN
+ http://struts.apache.org/dtds/tiles-config_1_3.dtd;
}}}
+
+ You can do much more to configure the ComposableRequestProcessor, but those
details are outside the scope of this document.
== 5 Deprecations which have been removed ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 The comment on the change is: Proposed release announcement, please contribute! -- || C4. || Post an announcement to lists and website || _ || + == Proposed Release Announcement == + + Subject: [ANNOUNCE] Struts Action Framework v1.3.4 [Alpha|Beta|] + + The Apache Struts team is pleased to announce the release of Struts Action Framework 1.3.4 [Alpha|Beta|for General Availability]. + + Struts Action is available in both a full distribution, and a library distribution containing only the framework and dependencies. + + http://struts.apache.org/download.cgi + + [Highlight new features?] + + The release notes are available online at: + + http://struts.apache.org/struts-action/userGuide/release-notes.html + + Notes on upgrading from prior versions can be found on the community-maintained wiki: + + http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || + || Bean Scripting Framework || 2.3.0 || Released || Scripting || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || @@ -77, +78 @@ || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || n/a || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || '''Note:''' Cactus tests are not working and have been moved to the sandbox. @@ -87, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit -SNAPSHOT || || + || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || (./) || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || - || A5. || Update all pom.xml files to 1.3.5-SNAPSHOT || || + || A5. || Update all pom.xml files to 1.3.5-SNAPSHOT || (./) || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || || A7. || Post release-quality vote on dev@ list |||| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of UserPreferences by wujiegao
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by wujiegao: http://wiki.apache.org/struts/UserPreferences -- + 第ä¸æ¬¡ä½¿ç¨ - ##language:en - [[UserPreferences]] - If you are coming to this page for the first time, you'll see the form into which you can enter your username and some other settings (password is stored, in plaintext, but currently not used). It is best to choose a WikiName (like Firstname``Lastname) as username to get your changes and signatures link back to your Wiki``Homepage. Entering your email will enable you to get notifications on page changes. - - If you click on '''Create Profile''', a user profile will be created for you. With the response, a HTTP cookie will be sent that contains your user ID, which enables the system to recognize you. - - /!\ ''This ID, shown in the response page, can be used to send the same cookie to other machines you might use. So jot it down! Or cut and paste the URL shown above, after you created your profile.'' - - '''Logout''' clears the cookie. As described above, '''Login''' enables you to gain access to your user profile if you somehow lost the cookie or are on another machine. '''Save''' just updates your profile. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || (./) || || A5. || Update all pom.xml files to 1.3.5-SNAPSHOT || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ list |||| + || A7. || Post release-quality vote on dev@ list || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of UserPreferences by GeorgeDinwiddie
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GeorgeDinwiddie: http://wiki.apache.org/struts/UserPreferences -- - 第ä¸æ¬¡ä½¿ç¨ + ##language:en + [[UserPreferences]] + If you are coming to this page for the first time, you'll see the form into which you can enter your username and some other settings (password is stored, in plaintext, but currently not used). It is best to choose a WikiName (like Firstname``Lastname) as username to get your changes and signatures link back to your Wiki``Homepage. Entering your email will enable you to get notifications on page changes. + + If you click on '''Create Profile''', a user profile will be created for you. With the response, a HTTP cookie will be sent that contains your user ID, which enables the system to recognize you. + + /!\ ''This ID, shown in the response page, can be used to send the same cookie to other machines you might use. So jot it down! Or cut and paste the URL shown above, after you created your profile.'' + + '''Logout''' clears the cookie. As described above, '''Login''' enables you to gain access to your user profile if you somehow lost the cookie or are on another machine. '''Save''' just updates your profile. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
The comment on the change is:
Note that the instructions apply to snapshots and distributions as well as svn.
--
Maven 2 does not use .properties files. Per-developer and per-system
configuration is done in '''~/.m2/settings.xml'''. (Where '~' represents the
user's home directory.) For more information, refer to the
[http://maven.apache.org/maven-settings/settings.html settings model] and the
Suggested Settings section below.
+ == Acquiring the Source Code ==
+
- == Checkout Source from Subversion ==
+ === Checkout Source from Subversion ===
The Struts Subversion repository is organized into sub-projects. You can
check out Struts Action 1 alone using this URL:
{{{
@@ -20, +22 @@
{{{
svn co https://svn.apache.org/repos/asf/struts/current current
}}}
+
+ === Snapshot or Distribution ===
+
+ The following instructions should work equally well from the 'src' directory
of a Struts Action snapshot or distribution. If they don't, let us know!
== Building with Maven ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsUpgradeNotes12to13 by NiallPemberton
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by NiallPemberton:
http://wiki.apache.org/struts/StrutsUpgradeNotes12to13
The comment on the change is:
Change notes to reference Validator 1.3.0
--
[http://jakarta.apache.org/commons/fileupload/ Commons FileUpload] version
1.1 (previously was version 1.0). As well as needing to upgrade the !FileUpload
jar you will now also need the
[http://jakarta.apache.org/commons/io/ Commons IO] Version 1.1 jar.
- === 3.3 Commons Validator 1.2.0 ===
+ === 3.3 Commons Validator 1.3.0 ===
Struts 1.3 now depends on
- [http://jakarta.apache.org/commons/validator/ Commons Validator] version
1.2.0 (previous was version 1.1.4) - remember to upgrade the Validator jar.
+ [http://jakarta.apache.org/commons/validator/ Commons Validator] version
1.3.0 (previous was version 1.1.4) - remember to upgrade the Validator jar.
- * Validator 1.2 will recognize config files from prior versions.
Optionally, you may
+ * Validator 1.3.0 will recognize config files from prior versions.
Optionally, you may
- * Change the doctype declaration at the top of validation.xml to refer to
the dtd for version 1.2
+ * Change the doctype declaration at the top of validation.xml to refer to
the dtd for version 1.3.0
{{{
!DOCTYPE form-validation PUBLIC
- -//Apache Software Foundation//DTD Commons Validator Rules
Configuration 1.2.0//EN
+ -//Apache Software Foundation//DTD Commons Validator Rules
Configuration 1.3.0//EN
- http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd;
+ http://jakarta.apache.org/commons/dtds/validator_1_3_0.dtd;
}}}
* If you change the doctype you will have to change the deprecated
''arg0-arg3'' elements to ''arg'' elements.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of SAF1RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots -- 1. '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. * [MichaelJ] Redirect-After-Post is fully implemented in [http://struts.sourceforge.net/strutsdialogs/index_v1.html Struts Dialogs 1.x]. After Struts 1.2.9 got better dispatch action, I stopped advertising Struts Dialogs project, but it is still valuable in terms of samples. Check it out. EventActionDispatcher and !EventDispatchAction can implement Redirect-After-Post as well, Paul and I spent quite some time discussing how !EventDispatchAction can be used for both input and render phases. + * [MichaelJ] To simplify redirect-after-post pattern, Struts must implement Flash scope, that is, the scope that survives after redirect, but is automatically cleaned up after redirected request finishes. Currently similar pattern is applied to the messages queued to session scope. 1. '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. * [MichaelJ] +0. I prefer having 1:1 correspondence between mapping and action class. With autopopulation out of the way, I can call whatever I want right in the beginning and at the end of execute() method. Same thing, but simpler, I think. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (./) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. @@ -75, +75 @@ === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || n/a || || 3. || Play test examples application (TC 5.0.x) || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease133 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || (./) || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || (./) || - || A5. || Update all pom.xml files to 1.3.4-SNAPSHOT || || + || A5. || Update all pom.xml files to 1.3.4-SNAPSHOT || (./) || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ and user@ lists || || + || A7. || Post release-quality vote on dev@ list || || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease133 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. - == Outstanding Bugs == + == Outstanding Issues == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21710 + + == Resolved Issues == + + http://issues.apache.org/struts/secure/ReleaseNote.jspa?version=21710styleName=TextprojectId=10121Create=Create == TO DO == @@ -90, +94 @@ || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || (./) || || A5. || Update all pom.xml files to 1.3.4-SNAPSHOT || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ list || || + || A7. || Post release-quality vote on dev@ list || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsReleasePlans by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsReleasePlans -- * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' * StrutsActionRelease133 - ''Struts Action Version 1.3.3'' + * StrutsActionRelease134 - ''Struts Action Version 1.3.4'' == 1.2.x == * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease134 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 New page: = Struts Action 1.3.4 Release = == Info == 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases] 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines] == Release Manager == The release manager is '''Wendy Smoak''' == How to Help == Everyone in the Struts community, users, developers, and committers, is encouraged to test a release, report any issues, and post to dev@ any comments on the overall quality of the release. To help everyone get started with Struts Action 1.3.4 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.4 distribution from http://svn.apache.org/dist/struts/action/v1.3.4/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) * Extract the distribution to a likely location (/opt/struts-action-1.3.4) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., /opt/struts-action-1.3.4/src) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. == Outstanding Issues == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21720 == Resolved Issues == http://issues.apache.org/struts/secure/ReleaseNote.jspa?version=21720styleName=TextprojectId=10121Create=Create == TO DO == == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list || || || 2. || Review/Resolve Outstanding Bugs || || || 3. || Update Release Notes || || || 4. || Check Dependencies || || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release Guidelines] is a helpful overall process backgrounder, but HTTPD does not use a test-build stage. External Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || '''Note:''' This release of Struts Action depends on Struts Build 1.0.0 for the Checkstyle config file. == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || || || 2. || Run Cactus Tests (see below) || || || 3. || Play test examples application (TC 5.0.x) || || '''Note:''' Cactus tests are not working and have been moved to the sandbox. == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || || A5. || Update all pom.xml files to 1.3.5-SNAPSHOT || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ list |||| == Vote (A) == || PMC Member || Quality || Voting thread is _ If release vote fails, including for a lack of quorum, remove from dist folder. == Point Release Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums
[Struts Wiki] Update of StrutsActionRelease133 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (discussed) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. @@ -63, +63 @@ || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || + + '''Note:''' This release of Struts Action depends on Struts Build 1.0.0 for the Checkstyle config file. == Testing Checklist == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease133 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || n/a || || 3. || Play test examples application (TC 5.0.x) || || + '''Note:''' Cactus tests are not working and have been moved to the sandbox. - === Cactus Tests === - - || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || - || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || || - || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || || - || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || || - || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || || - == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit -SNAPSHOT || || + || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease133 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || n/a || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || '''Note:''' Cactus tests are not working and have been moved to the sandbox. @@ -84, +84 @@ || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || || A5. || Update all pom.xml files to 1.3.4-SNAPSHOT || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMavenRelease by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMavenRelease
--
1. Create and upload signatures for all .jar and .pom files in
maven-snapshot-repository, and the .zip assembly file.
{{{
- ~/svn/struts/current/action
+ ~/svn/struts/STRUTS_ACTION_1_3_X
$ rm -rf $M2_REPO/org/apache/struts/action
$ mvn deploy -P pre-assembly,perform-itest
{about 20 minutes later...}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMavenRelease by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMavenRelease
The comment on the change is:
Combine deploy, site, and site:deploy
--
{{{
~/svn/struts/STRUTS_ACTION_1_3_X
$ rm -rf $M2_REPO/org/apache/struts/action
- $ mvn deploy -P pre-assembly,perform-itest
+ $ mvn deploy site site:deploy -P pre-assembly,perform-itest
{about 20 minutes later...}
- $ mvn site site:deploy
$ cd assembly
$ mvn assembly:assembly
$ scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
The comment on the change is:
add settings.xml schema
--
~/.m2/settings.xml
{{{
- settings
+ settings xmlns=http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
...
servers
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FrontPage by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/FrontPage -- * [:Shale:StrutsShale] -- A proposal for a next generation Struts architecture * StrutsTi -- A proposal and discussion pages for a next generation Struts architecture focusing on simplicity * [StrutsMoreAboutJSF] -- JSF vs. Struts (Is this still relevant?) + * StrutsAction1Planning -- Ideas for new versions of Struts Action Framework 1. * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion * [SAF1RoughSpots] -- Discussions of what can be done to continue the evolution of Struts Action1 Framework - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsAction1Planning New page: = Struts Action Framework 1 Planning = This page collects ideas and discussion on what could be included in future releases of Struts Action 1. This page is a whiteboard, meaning no one has committed to anything and therefore its purpose is to share information and brainstorm. == 1.3.x and beyond == The 1.3.x series utilizes Struts Chain as the default request processor and adds an extends attribute to all the configuration elements (a la Tiles). We would also like to add a Ant-style properties file to make variable substitutions within the XML elements. The substitution feature is supported by Spring and iBATIS, among others. Substitutions are a useful way to configure applications and reduce redundancy. == Experimental Members == To lay the groundwork for future changes, three experimental classes and interfaces are being added to the framework so that early adopters can experiment with using Struts Chain to develop applications. We do consider these members experimental, and they are subject to change, based on our experience using them with our own applications. '''ActionCommand''' - A Chain Command-like interface with one method: void execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. '''ActionContext''' - A Chain Context that implements the logical Action class API. Existing code could be converted by changing references to context.* and so forth. The context could be constructed by the Request Processor, as an optional Command in the Chain, so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface. '''ViewContext (pending)''' - A Chain Context that implements the logical Velocity Tools API. In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked experimental. The Commons Chain WebContext we now pass around Struts Chain could be called the StrutsContext to differentiate it from the ActionContext and ViewContext. (Are we now starting to call everything Context instead of Action? Not really. We use the Context suffix when a member extends Chain Context. This convention is unlike the current Action soup, since Context is a suffix that identifies a member's family history.) Another experimental member is the catalog element, which could be used to to support using a Chain of ActionCommands in lieu of an Action. == Struts Action Framework 1.4.x considerations == One we get past 1.3.x, there are some other things that we might consider. Consider combining DTDs. Right now, using standard extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground. == Struts Action Framework 1.5.x considerations == Based on our own work with the experimental members introduced in 1.3.x, we might consider some other changes. '''Consider a smart action type'''. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even try placing an ActionCommand interface on ActionForm, so people could skip having a seperate Action or ActionCommand class. The ActionForm could do it all. '''Consider a populate method on ActionForm'''. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on a god class to populate it from
[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsAction1Planning
--
To lay the groundwork for future changes, three experimental classes and
interfaces are being added to the framework so that early adopters can
experiment with using Struts Chain to develop applications. We do consider
these members experimental, and they are subject to change, based on our
experience using them with our own applications.
- '''ActionCommand''' - A Chain Command-like interface with one method:
+ '''!ActionCommand''' - A Chain Command-like interface with one method:
-
+ {{{
void execute(ActionContext context)
+ }}}
Support for conventional Actions would stay in place, but as an alternative,
a class could implement ActionCommand and unbind itself from the HTTP API.
- '''ActionContext''' - A Chain Context that implements the logical Action
class API.
+ '''!ActionContext''' - A Chain Context that implements the logical Action
class API.
Existing code could be converted by changing references to context.* and so
forth. The context could be constructed by the Request Processor, as an
optional Command in the Chain, so that it could be exposed this through
thread-local, opening the door for POJO actions that don't implement a
particular interface.
- '''ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
+ '''!ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
- In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the ViewContext. View technologies
could then look exclusively to the ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
+ In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the !ViewContext. View technologies
could then look exclusively to the !ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
- After having a chance to work with ActionContext and ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
+ After having a chance to work with !ActionContext and !ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
- The Commons Chain WebContext we now pass around Struts Chain could be called
the StrutsContext to differentiate it from the ActionContext and ViewContext.
+ The Commons Chain !WebContext we now pass around Struts Chain could be called
the !StrutsContext to differentiate it from the !ActionContext and
!ViewContext.
(Are we now starting to call everything Context instead of Action? Not
really. We use the Context suffix when a member extends Chain Context. This
convention is unlike the current Action soup, since Context is a suffix
that identifies a member's family history.)
- Another experimental member is the catalog element, which could be used to to
support using a Chain of ActionCommands in lieu of an Action.
+ Another experimental member is the catalog element, which could be used to to
support using a Chain of !ActionCommands in lieu of an Action.
- == Struts Action Framework 1.4.x considerations ==
+ == Struts Action Framework 1.4.x considerations ==
One we get past 1.3.x, there are some other things that we might consider.
- Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
DynaForm configuration.
+ Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
!DynaForm configuration.
- Consider refactoring for Spring. We identified the need for adding a IOC
container to Struts some time ago, but stalled on the point of which to use.
Since then, Spring
[Struts Wiki] Update of Shale by AndrewKuzmin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by AndrewKuzmin: http://wiki.apache.org/struts/Shale -- * [:/UserDocs:User Documentation] - Shale user docs on the wiki. * [:/Resources:External Resources] - Articles, tutorials, books etc. on Shale. * [:/JsfResources:JavaServer Faces] - JSF Resources. + * [http://www.java201.com/resources/tags/shale Shale Related Resources] - Articles, Books, Presentations, Tutorials. === Project Maintenance and Resources === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Shale/UserDocs by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/Shale/UserDocs The comment on the change is: Added a link for Clay -- == User Documentation == * [:Shale/GettingStarted:Getting Started with Shale] * [:ShaleCoreLibrary:Shale Core Library] + * [:ShaleClay:Shale Clay] * [:ShaleTestFramework:Shale Test Framework] * [:ShaleRemoting:Shale Remoting] * [:ShaleValidation:Shale Validation] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ShaleClay by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay New page: Describe ShaleClay here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ShaleClay by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay The comment on the change is: Adding Debugging Tips -- Describe ShaleClay here. + DebuggingShaleClay + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of DebuggingShaleClay by RyanKanno
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
New page:
== Incorrect public id ==
=== Problem ===
When running a web application in offline mode (ie, no Internet), ShaleClay
attempts to download the appropriate dtd to validate the various ShaleClay
configuration files. However, with no Internet connection, the web server
should report the following error:
{{{java.net.UnknownHostException: struts.apache.org
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)}}}
=== Solution ===
The reason is that there is an incorrect public id in one (or more) of your
ShaleClay configuration files.
The correct public id should be:
{{{-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN}}}
=== See ===
[http://www.mail-archive.com/user%40struts.apache.org/msg45712.html Struts
Mailing List Message]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of DebuggingShaleClay by RyanKanno
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
--
+ Various tips on helping debug the various issues that a developer would find
using ShaleClay.
- == Incorrect public id ==
+ [[TableOfContents()]]
+ === Incorrect public id ===
+
- === Problem ===
+ Problem
When running a web application in offline mode (ie, no Internet), ShaleClay
attempts to download the appropriate dtd to validate the various ShaleClay
configuration files. However, with no Internet connection, the web server
should report the following error:
{{{java.net.UnknownHostException: struts.apache.org
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)}}}
- === Solution ===
+ Solution
The reason is that there is an incorrect public id in one (or more) of your
ShaleClay configuration files.
@@ -18, +21 @@
{{{-//Apache Software Foundation//DTD Shale Clay View Configuration
1.0//EN}}}
- === See ===
+ See
[http://www.mail-archive.com/user%40struts.apache.org/msg45712.html Struts
Mailing List Message]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ShaleClay by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay -- - Describe ShaleClay here. - DebuggingShaleClay + * DebuggingShaleClay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of WhyChain by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/WhyChain The comment on the change is: Added some pictures (will need to refactor the chain docs) -- the implementation of the new ComposableRequestProcessor class in Struts 1.3. + == Struts 1.0 == + In Struts 1.0, requests were processed using a lump of code in ActionServlet. To keep it organized, the code was subdivided in a series of methods. Unsurprisingly, each method in the series had a coherent task and was named after its task. + == Struts 1.1.x - 1.2.x == + In Struts 1.1, we pulled out that lump of code and turned it into a first class object called the RequestProcessor. The original methods remained mainly the same, but now they were methods in a coherent object, rather than a set of related methods in a larger object. + + inline:struts12rp.gif Since it was a first-class object, we could subclass this new request processor, and plug in a new one, without touching the Servlet. (Users do not like to subclass ActionServlet.) We were also able to use a different request processor for each module, if need be. The problem is that it was still an all-or-nothing object. Extensions like Tile and Workflow both needed to subclass the RequestProcessor in different ways for their own reasons. + + == Struts 1.3.x == For Struts 1.3, we turned the 1.1 request processor methods into Commands. Rather than subclassing a monolithic object, we could now just replace Commands. We could also insert or remove Commands, if needed, to extend or streamline the request processing gauntlet. @@ -28, +36 @@ * A flexible processing layer for business applications * An extensible request processor for Struts - The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the business logic of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR :) + The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the business logic of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR + + inline:struts13rp.gif Yes, Struts Chain is a challenging application for CoR, and the implementation is not as slick as we might like. But, challenge is a good thing. And, I'm sure as more of us gain experience using CoR in other contexts, we'll devise more elegant solutions. The great thing about CoR is that it's easy to refactor. I'm using CoR in my own applications, and it's working quite well. I hope to start reapplying some of that experience to Struts Chain, and I'm sure others will too. + + inline:struts13rp2.gif + Here is a link to Ted's message in the archives: http://marc.theaimsgroup.com/?l=struts-devm=111097810923548w=2 + Other links: + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html + + http://www.infonoia.com/en/content.jsp?d=inf.05.06pr=1 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of WildcardsForActionMappings by afattahi
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by afattahi:
http://wiki.apache.org/struts/WildcardsForActionMappings
New page:
== WildcardsForActionMappings ==
One of the new features in Struts 1.2. is the support of wildcards for action
mapping. A sample could be found at
http://struts.apache.org/struts-action/userGuide/building_controller.html#action_mapping_example
This feature can be used in advance to generalize the actions even more.
Consider below as a very usual example:
Imagine a system which has an accounting form that enables user to inserts,
updates and search for its accounts. This system also has a product form which
does the same for product.
A good deign is to do encapsulate all related forms actions (search, edit, form
initialization etc...) in one FormAction.
If we put all action in one java action, then will we found which action must
take place for each request to the form? Is this request for editing account or
searching it? Well, we can use the old fashion(!) DispatchLookUpAction and deal
with dispatch parameter.
Another alternative is using action wild cards consider below sample:
=== Example ===
{{{
action path=/**/*Form !-- we path to parameter here--
type=com.mycompany.{1}FormAction
name={1}{2}FormBean
parameter=dispatch
validate=false
scope=request
forward name=show.Search.form
path=/main/form/{1}{2}Form.jsp/
forward name=show.Edit.form
path=/main/form/{1}{2}Form.jsp/
forward name=success.Search
path=/main/form/{1}{2}Form.jsp/
forward name=success.Edit
path=/main/form/{1}{2}Form.jsp/
Too bad struts does not support wild card for forward names!!!
}}}
The above pattern accepts /Account/EditForm.do, /Account/SearchForm.do,
/Product/SearchForm.do etc...
So no need for sending dispatch parameter, the url itself contains the
requested action (Edit,Search).
In your action, you can get this second parameter by parsing the request URI.
(Maybe strust has a utility for it!)
Below code does this by calling the getMethod,
{{{
String getActionPath(HttpServletRequest req) {
String path;
path = req.getRequestURI();
path = path.substring(path.lastIndexOf('/') + 1);
return path;
}
String getMethod() throws WebException {
String method = getActionPath(Req);
//Assume that the path is /Account/SearchForm.do etc...
method = method.replaceAll(Form.do, );
log.debug(Method ' + method + ' found from action path.);
if (!method.equals(EDIT_FORM_METHOD)
!method.equals(SEARCH_FORM_METHOD)) {
throw new WebException(Invaild internal Method,
WebException.INVALID_INPUT);
}
return method;
}
}}}
So: user calls /Account/EditForm.do Struts calls AccountFormAction class. And
in this action you can get the actual method. Struts also forwards to proper
jsp, which for this sample it will be /main/form/AccountEditForm.jsp
Imagine the lot that you can do when mixing above feature with a nice parent
class, which does all same tasks for actions by itself, and only calls use
casespecific methods.
As you might have notice all forms have the same flow and same task should be
done for all of them, form should be displayed, after user submitted back the
form, form must be validated first for user input ( not null fields etc) then
for business validation. If user did not entered valid data, form is
initialized and send back to user
So you can create a parent for all form actions, like below:
{{{
public abstract class BaseFormAction
{
execute()
{
//YOU CAN DO LOT HERE
//get the method();
//Validate user inputs. If there is an error forward to show.METHOD.from
//This METHOD will be Edit or Search
//if method is search
// call Search();
// if method is add
// call Add()
}
abstract Search()
abstract initSearch()
abstract Edd()
abstract initEdd()
}
}}}
All abstracts will be implemented in actual classes ( AccountFormAction ).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of WildcardsForActionMappings by afattahi
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by afattahi: http://wiki.apache.org/struts/WildcardsForActionMappings -- } abstract Search() abstract initSearch() - abstract Edd() + abstract Edit() - abstract initEdd() + abstract initEdit() } }}} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of SAF1RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots -- == Code Issues == - 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O conversion. !FormDef seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. + 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O conversion. [https://formdef.dev.java.net/ FormDef] seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. - 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. + 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple; from a user's perspective it includes just reset/populate/validate functions. Consider the option to call all lifecycle functions explicitly from an action class, no more automatic population. * [FrankZ] I personally would not want to see the auto-population and validation and such go away. I think them being declarative is a powerful notion. I DO however agree that a developer should be able to turn them off declaratively and do it all manually. - * [MichaelJ] Considering to call lifecycle functions explicitly does not mean removing autopopulation from the next release :) 1. '''Automatic validation''' [MichaelJ] Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. * [FrankZ] Definite -1 from me. Again, I'm +1 to being able to turn it on and off, but I very much believe it should be there. Perhaps there is some room for better logging in the cases you mention? - * [MichaelJ] Deprecating autovalidation does not mean removing that feature from the next release :) I hope you reconsider your -1 or do you want me to remove deprecate word entirely? I think that without autovalidation things will be clearer: action class will always be called, and different error conditions with different targets can be supported. 1. '''Input attribute''' [MichaelJ] Deprecate input attribute of action tag in struts-config.xml. At least, rename it to error or something. A frequent misconception is to think that the lifecycle starts with displaying an input page, which is obviously not true. * [FrankZ] +0. I don't disagree with you at all, and I think there are probably other things that could similarly be changed. However, I think it is very important that anything done with SAF1 be evolutionary and take backwards-compatibility into consideration in a big way. I think if you want revolution you go for SAF2 (a minor revolution in that it's theoretically still compatible) or Shale. - * [MichaelJ] Hey Frank, now ''you'' are writing me off the boat? ;) What if I want some revolution staying within SAF1 codebase? 1. '''Form attribute''' [MichaelJ] Add form attribute with the same meaning as name attribute; deprecate name. * [FrankZ] +0. Same comment as the above point. - * [MichaelJ] Again, add means add. It does not mean removing name in the next release. 1. '''Differentiate forward from redirect in mappings''' [MichaelJ] forward tag implements both forward and redirect, this is confusing. Implement two separate tags like render for forward and transfer for redirect. forward tag still can be kept for compatibility purposes. * [FrankZ] Hmm, I'm not sure how I feel about that. Maybe simply adding a type attribute, ala Webwork, would do the trick? forward or redirect as values? @@ -46, +42 @@ /component }}} - This mapping use new format for action mapping. component is essentially action with different defaults and some new elements. This is 1:1 correspondence between mapping and action class. Same action class handles input phase as well as render phase (I saw your remark about Redirect-After-Post, here it is, implemented). + This mapping uses the action mapping format introduced in Struts Dialogs project. A component is essentially an action with different defaults and some new elements. This is 1:1 correspondence between mapping and action class. Same action class handles input phase as well as render phase (I saw your remark about Redirect-After-Post, here it is, implemented). 1. '''!DispatchActions''' [MichaelJ] Having that many dispatching actions in the distro, all of them but
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
--
== Integration Testing ==
- The Maven 2
[http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
build lifecycle] includes a phase for integration testing. Currently, a module
may contain only unit tests ''or'' integration tests, but not both. See the
[http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies
testing strategies] page for discussion and proposals.
+ The Maven 2
[http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
build lifecycle] includes a phase for integration testing. See the
[http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies
testing strategies] page for discussion and proposals.
Integration tests for Struts Action are located under the '''integration'''
module. Integration tests will only be run if the ''perform-itest'' profile is
enabled.
-
- === Cactus Tests ===
-
- The Cactus tests for Struts Taglib are located in the
action/integration/taglib-it module. To run the tests, you must provide a
value for the 'cargo.tomcat5x.home' System property, for example:
- {{{
-~/svn/struts/current/action/integration/taglib-it
-$ mvn -P perform-itest -Dcargo.tomcat5x.home=c:/java/apache-tomcat-5.5.16
- }}}
-
- (This will run the default '''install''' goal which includes the
'''integration-test''' phase.)
-
- See the Suggested Settings section below for information on configuring the
'cargo.tomcat5x.home' System property in your settings.xml file, so that you
don't have to specify it on the command line.
-
- There is no Cactus plugin for Maven 2, so
- * The Struts Taglib testing webapp is manually configured for Cactus with
extra information in web.xml, and a jspRedirector.jsp file in the root
directory.
- * Executions of the Surefire, Compiler, War, and Cargo plugins are bound to
various lifecycle phases
-
- '''NOTE:''' If the tests fail, Cargo will not be able to stop the container.
=== Apps ===
@@ -92, +74 @@
}}}
Then visit http://localhost:8080/webappname in your browser. This requires
that the cargo.tomcat5x.home system property is set, usually either on the
command line (-Dcargo.tomcat5x.home=...) or in ~/.m2/settings.xml. See the
Suggested Settings section, below.
+ === Cactus Tests ===
+
+ The Cactus tests for Struts Taglib are not working and have been moved to the
sandbox/apps-test/taglib-it module.
== Suggested Settings ==
@@ -154, +139 @@
To avoid repeated password prompts, configure the apache-maven-snapshots
server in ~/.m2/settings.xml.
+ == Releases ==
+
+ * StrutsMavenRelease
+
== References ==
* [http://www.mergere.com/m2book_download.jsp Better Builds With Maven] -
free book from Mergere (requires registration)
* [http://www.developer.com/open/article.php/10930_3552026_2 This article]
provides a good introduction to Maven 2 and lists some other useful goals.
- * StrutsMavenRelease
== TODO ==
* Consolidate some of the example apps to reduce the size of the
distribution (?Suggested by Don?)
* Create a custom deployment plugin to handle promoting our test builds from
cvs.apache.org/maven-snapshot-repository to
www.apache.org/dist/maven-repository.
* http://www.nabble.com/Re%3A-m2-Releases-and-test-builds-p3824610.html
- * Figure out how to run the Cactus tests in 'integration/el-it' against the
strutsel-exercise-taglib webapp which is in the 'apps' module.
+ * Figure out how to run the Cactus tests in 'sandbox/apps-test/el-it'
against the strutsel-exercise-taglib webapp which is in the 'apps' module.
* http://www.nabble.com/Cargo-and-Maven-2-and-Cactus-t1420342.html
* Fix the Cactus tests for Struts Taglib
* Revisit the war plugin configuration for including the source code in the
example webapps under WEB-INF/src. This is currently being done with an
execution of the antrun plugin in apps/pom.xml. Martin mentions that a
webResources element is present in the war plugin source, but it does not
appear to be available in the latest released version.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceWebsite by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceWebsite
--
- After the subproject reorganization:
+ === Edit ===
+ * Edit the src/site/site.xml and src/site/xdoc/*.xml files.
+ * Execute 'mvn site' from the top level of the project, for example:
'struts/current/action'
- * Edit the xdocs/*.xml files.
- * Run 'maven multiproject:site' from the 'site' subproject (NOT from 'build')
+ === Preview ===
+ * To preview the site locally: 'mvn site:run' (?? Might not work yet, or
might require a snapshot of maven-site-plugin)
+ * Or point your browser at target/site/index.html (but be aware that
relative links to modules won't work)
+
+ === Deploy ===
+
+ * To deploy: mvn site:deploy (See the Suggested Settings section on
StrutsMaintenanceMaven to avoid repeated password prompts)
+
+ Or
+
- * From the command line, change to the site/target/docs directory
+ * From the command line, change to the site/target/site directory
* scp the website files to people.apache.org.
* Using PuTTY, the command is: pscp -r *.* [EMAIL
PROTECTED]:/www/struts.apache.org
* Using Cygwin, the command is: scp -r * [EMAIL
PROTECTED]:/www/struts.apache.org
- * After an hour, the copy on people will propogate to the main website. (So
test your local copy first!)
* You can update the site for a single sub-project by using the correct
destination path. For example:
{{{
- /svn/struts/current/tiles
+ /svn/struts/current/action/tiles
$ maven clean site
...
- $ scp -r target/docs/* [EMAIL PROTECTED]:/www/struts.apache.org/struts-tiles
+ $ scp -r target/site/* [EMAIL PROTECTED]:/www/struts.apache.org/struts-tiles
}}}
+ After you deploy the site, check the permissions!
+ === Permissions ===
- (See also: 'maven site:deploy' on
http://maven.apache.org/maven-1.x/reference/plugins/site/)
-
- Note:
* Everyone should ssh to people.apache.org and set your umask to 002 ($
umask 002). This will mark the files so that other people in the Struts group
can update them.
* If the permissions are not set correctly, you can fix it with: $ chmod -R
g+w .
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMavenRelease by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMavenRelease
--
= Struts Maven 2 Release Process =
- == 1. Releasing Struts Action ==
+ == 1. Releasing Struts Action 1 ==
1. Create the new directory on cvs.apache.org, for example
cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x')
1. Ensure that your settings.xml contains a server for
apache-maven-test-builds (see the Suggested Settings section on
StrutsMaintenanceMaven)
1. Clear out your local Maven repo
- 1. Build all jar and war artifacts, including -sources and -javadoc,
+ 1. Build, test and deploy all jar and war artifacts, including -sources and
-javadoc.
- 11. verifiy war files
- 111. cd to {your struts checkout}/action/integration/apps-it
- 111. run $mvn -P perform-itest
- 11. deploy them to maven-snapshot-repository.
1. Build and deploy the website
1. Create the assembly and upload it to cvs.apache.org/dist
- 1. Make sure that everything under
maven-snapshot-repository/org/apache/struts is group writeable
+ 1. Make sure that everything under
maven-snapshot-repository/org/apache/struts/ and
www/struts.apache.org/struts-action is group writeable
- 1. Create and upload signatures for all .jar and .pom files in
maven-snapshot-repository, and the .zip, and .tar.gz files.
+ 1. Create and upload signatures for all .jar and .pom files in
maven-snapshot-repository, and the .zip assembly file.
{{{
+ ~/svn/struts/current/action
- rm -rf $M2_REPO/org/apache/struts/action
+ $ rm -rf $M2_REPO/org/apache/struts/action
- mvn deploy -P pre-assembly
+ $ mvn deploy -P pre-assembly,perform-itest
{about 20 minutes later...}
- mvn site site:deploy
+ $ mvn site site:deploy
- {may have to deploy the site for each module individually}
- cd assembly
+ $ cd assembly
- mvn assembly:assembly
+ $ mvn assembly:assembly
- scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x
+ $ scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x
}}}
== 2. Releasing the struts-parent pom ==
- 1. Update the version number in pom/pom.xml (remove -SNAPSHOT) and commit
changes
+ 1. Update the version number in maven/pom/pom.xml (remove -SNAPSHOT) and
commit changes
1. Post release vote on dev@
1. 'mvn deploy' to deploy to dist/maven-repository
1. Upload a signature for the deployed pom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Explicitly pointed to JIRA repository -- == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21699 + + == Where To Report Bugs == + + Use JIRA to report issues: + + http://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=showcreateNew=true + + Do not use Apache Bugzilla (it does not accept Struts bugs anyway). == TO DO == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Link to the Action 1 project summary instead, and note that login is required. -- == Where To Report Bugs == - Use JIRA to report issues: + Use JIRA to report issues: http://issues.apache.org/struts/browse/STR - http://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=showcreateNew=true + You will have to [http://issues.apache.org/struts/secure/Dashboard.jspa?os_destination=%2Fbrowse%2FSTR Login] before you can create a new issue. Do not use Apache Bugzilla (it does not accept Struts bugs anyway). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FrontPage by afattahi
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by afattahi: http://wiki.apache.org/struts/FrontPage -- * StrutsSolutions -- A page to find solutions to common ways of doing things-type questions * [StrutsIDEGuides] -- Guides to help IDE users work on and with Struts * StrutsLogging -- How to enable logging so that you can see more messages from Struts + * WildcardsForActionMappings -- How to use advance wildcards === Project Maintenance and Resources === * StrutsReleasePlans -- Release plans for each Struts release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- /table }}} * [jcarreira] That depends on whether you're using the form tag or not, but agreed... the XHTML theme should be cleaned up and made the default. - * [tm_jee] XHTMl them is currently the default, if not mistaken. + * [tm_jee] XHTML theme is currently the default, if not mistaken. 1. File upload should support progress notification. Have a look at webwork-multipart on java.net, it's based on the pell parser but has a progress API. * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class that looks at the file as it's uploading to see how big it is on disk @@ -282, +282 @@ * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + * [tm_jee] I agree with Phil, I still like configuring through configuration without recompilation. 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. @@ -338, +339 @@ * [jcarreira] I think this is a bad idea, in general. Actions should specify the exact things they need and have them supplied, not just ask for the world (the ActionContext is the world the action lives in). * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. * [plightbo] Tim's suggestion of allowing actions to get the ActionContext without referencing the thread local is a good one. This is in line with other requests to reduce the number of situations where users have to deal with ThreadLocals. + * [tm_jee] I think its ok, if we allow action to implements say ActionContextAware and have an interceptor inject the ActionContext into it. 1. HTML analog tags should stick to HTML attributes. I don't mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like actionName, actionAddress, etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + media attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? * [mrdon] +1 for aligning attributes with HTML attributes + * [tm_jee] -1. If I'm not mistaken I think WW's tag are doing stuff in a broader perspective, typically in a theme perspective and I hope we could still keep it that way, if possible. A textfield for example, merely says its a textfield, how it behaves is entirely up
[Struts Wiki] Update of RoughSpots by RainerHermanns
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by RainerHermanns: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? * [mrdon] +1 for aligning attributes with HTML attributes * [tm_jee] -1. If I'm not mistaken I think WW's tag are doing stuff in a broader perspective, typically in a theme perspective and I hope we could still keep it that way, if possible. A textfield for example, merely says its a textfield, how it behaves is entirely up to the particular theme. Normally, one would extends from a parent theme, and overide those components' template that they want alteration accordingly or introduce other templates that could co-exists with their counterparts to skin the component. + * [rainerh] Big -1... The ww tags are no dynamic replacement for simple HTML tags, but a complete set of UI components. With these themeable components small and large webapps can be easily build. All (important) HTML attributes are supported, not for the simple tags, but for the complete component. 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you want to return anything that requires more than the symbol, you have to do some less than intuitive things to make the Action and the Result cooperate. I'd prefer to see a concrete Result get returned from Action methods, which would allows developers to do more powerful things more easily. There are a bunch of ways to make it backward compatible too. You could return 'new SymbolicResult(success)' and have the SymbolicResult do the lookup stuff (You could even redefine the String constants to be SymbolicResults). You could alternatively use a static class to do Results.find(SUCCESS). Or you could even allow method to continue to return String or Result, and if String wrap it in a SymbolicResult. * [frankz] +1. This is one area where I personally think Struts had it right and we've seen frameworks getting it wrong subsequently. !ActionForward I believe is the right concept, even if the realization might not be optimal. I think the difference between return ok; and return new ActionResult(ok); is pretty minimal, but the later opens up a lot of possibilities being a true object that can have behaviors and properties and such. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- result name=inputaddPerson.jsp/result /action}}}The ValidationInterceptor should still cause an input result to occur but if we make it through to invoking the action and there is no execute method we return the value of the configured assumed result. + 1. When an action returns `LOGIN`, save the request in the session (even POSTs) and enable the user to re-execute it after login. + == What JDK Version? == * [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year... Everything we write and wire together is using generics and annotations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Eric Molitor
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Eric Molitor:
http://wiki.apache.org/struts/RoughSpots
--
1. [molitor] Modular Ant Build, I've started working on this using the
build files that Jason supplied (which were forwarded on to me). Allows the
project to build in whole or in part with seperate build files that extend a
set of common/parent build files. Should parallel the maven build.
* [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to
get familiar with Maven and would like to keep an alternate optiona available.
:-)
+ 1. [molitor] Ability to use values on the stack to override/define
configuration options. My patch for the StreamResult is just one application of
this, there are many others.
+
+ 1. [molitor] Ability to invoke an action without an execute method. If I
annotate a class with @assume_success (or something like @assumed
result=SUCCESS) I shouldn't need an execute method. In XML this could be
achieved something like this.{{{action name=addPerson
class=com.opensymphony.webwork.showcase.person.AddPerson
assumeResult=success
+resultshowPerson.jsp/result
+result name=inputaddPerson.jsp/result
+ /action}}}The ValidationInterceptor should still cause an input result to
occur but if we make it through to invoking the action and there is no execute
method we return the value of the configured assumed result.
+
== What JDK Version? ==
* [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year...
Everything we write and wire together is using generics and annotations.
@@ -442, +449 @@
* [crazybob] You're right. That's actually been my experience, too. I'm
fine with supporting 1.4 (though I'd prefer not to have to write the code as I
haven't used it for some time).
* [rainerh] +1 for Java 5 support
* [tm_jee] +1
+ * [molitor] +1 for JDK 1.5+
* [niallp] +1 for JDK 1.5 (btw I did a
[http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL
PROTECTED] POLL on what jdk people used] in Jan). Although it will prevent some
users upgrading, maybe for others it will be part of the ''tipping point'' to
encourage them to move to 1.5. Also what will the JDK landscape look +1 year
from now - I believe most users take their time before upgrading, so thats
probably a realistic timescale for the vast majority to consider SAF2.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates + [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMavenRelease by JamesMitchell
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by JamesMitchell:
http://wiki.apache.org/struts/StrutsMavenRelease
The comment on the change is:
Add item for testing the apps with Wendy's new super-cool-webapp-tester-thingee
--
1. Create the new directory on cvs.apache.org, for example
cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x')
1. Ensure that your settings.xml contains a server for
apache-maven-test-builds (see the Suggested Settings section on
StrutsMaintenanceMaven)
1. Clear out your local Maven repo
- 1. Build all jar and war artifacts, including -sources and -javadoc, and
deploy them to maven-snapshot-repository.
+ 1. Build all jar and war artifacts, including -sources and -javadoc,
+ 11. verifiy war files
+ 111. cd to {your struts checkout}/action/integration/apps-it
+ 111. run $mvn -P perform-itest
+ 11. deploy them to maven-snapshot-repository.
1. Build and deploy the website
1. Create the assembly and upload it to cvs.apache.org/dist
1. Make sure that everything under
maven-snapshot-repository/org/apache/struts is group writeable
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by plightbo
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by plightbo: http://wiki.apache.org/struts/RoughSpots -- [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is - [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [plightbo] Agreed - examples, default results, etc should be JSP. However, we need to keep UI tags in a template language so they can be used in all view technologies. Right now that is FreeMarker, though if we can find a template language that is more like JSP (say, without the scripplets), I would like to switch to that. 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we use it extensively. It's the best validation framework I've seen out there, and NO, validate methods are NOT enough. For instance, we define reusable validations for our domain models and use them for both the web front end as well as web services and batch imports. * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. - * [rainerh] -1 on removing the valdation framework. This is one of the best, if not the best validation framework I've seen so far. + * [rainerh] -1 on removing the validation framework. This is one of the best, if not the best validation framework I've seen so far. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [jcarreira] You're kidding, right? We've discussed this already @@ -243, +244 @@ * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + * [plightbo] The reference docs are great, but we failed terribly on the
[Struts Wiki] Trivial Update of RoughSpots by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates - [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. + * [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. @@ -238, +238 @@ * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [phil] -1 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. @@ -274, +276 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. + + /!\ '''Edit conflict - other version:''' * [phil] -1 + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + + /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + + /!\ '''Edit conflict - your version:''' + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. + + /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -276, +291 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + + /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -297, +318 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here:
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. - - /!\ '''Edit conflict - other version:''' * [phil] -1 - - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 - - /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). - - /!\ '''Edit conflict - your version:''' - * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. - /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -291, +279 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) - - /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -318, +301 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https://issues.apache.org/struts/browse/WW-1133]. * [plightbo] I still don't
[Struts Wiki] Update of RoughSpots by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Comment on JDK 1.5 -- * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). * [rainerh] +1 for Java 5 support * [tm_jee] +1 + * [niallp] +1 for JDK 1.5 (btw I did a [http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL PROTECTED] POLL on what jdk people used] in Jan). Although it will prevent some users upgrading, maybe for others it will be part of the ''tipping point'' to encourage them to move to 1.5. Also what will the JDK landscape look +1 year from now - I believe most users take their time before upgrading, so thats probably a realistic timescale for the vast majority to consider SAF2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Drop several TODOs that are either done, in progress, or in JIRA. -- * Consolidate some of the example apps to reduce the size of the distribution (?Suggested by Don?) * Create a custom deployment plugin to handle promoting our test builds from cvs.apache.org/maven-snapshot-repository to www.apache.org/dist/maven-repository. * http://www.nabble.com/Re%3A-m2-Releases-and-test-builds-p3824610.html - * Finish converting the xdocs to src/site/site.xml and src/site/xdoc, figure out how the Struts Action site will be arranged and put redirects in .htaccess if necessary. * Figure out how to run the Cactus tests in 'integration/el-it' against the strutsel-exercise-taglib webapp which is in the 'apps' module. * http://www.nabble.com/Cargo-and-Maven-2-and-Cactus-t1420342.html * Fix the Cactus tests for Struts Taglib * Revisit the war plugin configuration for including the source code in the example webapps under WEB-INF/src. This is currently being done with an execution of the antrun plugin in apps/pom.xml. Martin mentions that a webResources element is present in the war plugin source, but it does not appear to be available in the latest released version. * http://www.nabble.com/-m2-Including-the-source-code-in-a-war-t1409417.html * http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html - * Document the Struts Maven 2 release process: StrutsMavenRelease - * Integration tests for the webapps under various container/JDK combinations - * Remove the Tiles dependency from EL (Move the tiles-el tags to Struts Tiles) - * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. + * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. (A brief look says there isn't as much duplication as I thought; this might not be necessary.) - * Add reporting section to action/trunk/pom.xml and generate Javadoc and other reports for the website. - * Reorganize any files found in conf/java and src/conf into src/main/resources and remove the resource tags from pom.xml. - * Update the Struts Action Blank Archetype (groupId dependencies) and move it out of the sandbox to action/archetypes/action-blank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
The comment on the change is:
Add notes on the apps-it module
--
'''NOTE:''' The 'assembly:assembly' goal must be run from action/assembly.
Somehow, this needs to be coordinated with release:prepare and release:perform,
so that the assembly will contain the same jars that were just deployed to the
repository.
-
- === Source Assembly ===
-
- * The source code is included in struts-action-x.x.x-all.zip.
-
- * Wait for v2.1 of maven-assembly-plugin, then consider switching to the
action/assembly/src/main/assembly/src.xml and dep.xml descriptors for separate
-bin and -src assemblies.
-
- * See StrutsMaven2Plan for some additional thoughts on assemblies.
-
== Integration Testing ==
The Maven 2
[http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
build lifecycle] includes a phase for integration testing. Currently, a module
may contain only unit tests ''or'' integration tests, but not both. See the
[http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies
testing strategies] page for discussion and proposals.
@@ -88, +79 @@
=== Apps ===
- Tests for the '''apps''' module are not currently automated with Maven 2.
+ The integration/apps-it module contains tests to confirm that each example
app starts and displays its default page:
+ {{{
+~/svn/struts/current/action/integration/apps-it
+mvn -P perform-itest
+ }}}
- However, each module inherits Cargo plugin configuration (from apps/pom.xml)
which will start Tomcat 5.x and deploy the app:
+ In addition, each module inherits Cargo plugin configuration (from
apps/pom.xml) which will start Tomcat 5.x and deploy the app:
{{{
+ ~/svn/struts/current/action/apps/[module]
mvn package cargo:start
}}}
Then visit http://localhost:8080/webappname in your browser. This requires
that the cargo.tomcat5x.home system property is set, usually either on the
command line (-Dcargo.tomcat5x.home=...) or in ~/.m2/settings.xml. See the
Suggested Settings section, below.
@@ -133, +129 @@
profile
idcargo-config/id
properties
-
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.16/cargo.tomcat5x.home
+
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.17/cargo.tomcat5x.home
cargo.tomcat4x.homec:/java/jakarta-tomcat-4.1.31/cargo.tomcat4x.home
/properties
/profile
@@ -161, +157 @@
== References ==
* [http://www.developer.com/open/article.php/10930_3552026_2 This article]
provides a good introduction to Maven 2 and lists some other useful goals.
+ * StrutsMavenRelease
== TODO ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Add link to the Maven book -- == References == + * [http://www.mergere.com/m2book_download.jsp Better Builds With Maven] - free book from Mergere (requires registration) * [http://www.developer.com/open/article.php/10930_3552026_2 This article] provides a good introduction to Maven 2 and lists some other useful goals. * StrutsMavenRelease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by JasonCarreira
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by JasonCarreira: http://wiki.apache.org/struts/RoughSpots -- 1. Do we want to keep `ModelDriven`? * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. * [plightbo] I think we should give some serious thought to this. Look around the internal implementation of WebWork/XWork as well as the number of questions that come up on the mailing lists. It's a very confusing thing, especially when interacting with setting or getting values of form fields. + * [jcarreira] yes, it makes the internal implementation more complex, but it makes things easier for the user of the framework in a lot of cases. If people are confused by it, they can choose not to use it. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -266, +267 @@ 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic Environment api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. * [plightbo] +1. we should keep this in mind when designing the API. + * [jcarreira] -1 to using the HttpServletRequest... Why do we need it? We've got a nice abstraction with the Maps for parameters, session, and application scopes, I think. Why tie to the servlet API and make a phony one to proxy to Portlets? 1. Add action and method attributes to the submit button tag so users don't have to know about the action:Name and method:name conventions. * [plightbo] We already do this :) @@ -296, +298 @@ * [jcarreira] I think we should have some pre-defined ones for standard things: view vs. CRUD vs. action - do somthing that's not CRUD. We should then use annotations to make it where you can declaratively associate a particular action method with a stereotype which is mapped to an interceptor stack, etc. * [crazybob] C[R]UD isn't a good name because view == [R]etrieve. Let's call it update for the moment. What will the difference be between update and action? * [plightbo] I really don't think having a update and action stack is a good idea. Let's make a single stack and then have the stack behave differently depending on the context in which the action was executed. There are several options (GET vs POST, method names, annotations, etc). + * [jcarreira] I really think this is a bad idea and will lead to great suffering... We put in interceptors to allow people to customize the processing of a request, why move away from that now? I think if we do some thinking we can think of the common use-cases that cover 80+% of the action cases, and make it very easy for an action developer to tag this action as using one of that small number of stereotypical uses. The action will then pick up the configuration set up for that stereotype (which could include things like defaulting the result pages to go to, etc.) == Gabe's Issues == 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. * [plightbo] Let's not dismiss Tim's comments too quickly. While we might not implement a solution exactly like he suggests, his point is valid that handling state management in WebWork has always been a very week area. The ScopeInterceptor isn't a great option either, especially considering one of my other issues specifically asks that we avoid having to create custom interceptor stacks for various actions. * [jcarreira] I'm open to hearing good ideas for state management. Especially short-lived wizard type state. Long lived session state (things like your user profile) work really well as Spring session-scoped components, but state which is just used for the next 4 or 5 pages isn't such a good fit. + * [MJ] I think talking in terms of pages does not really get us further from ancient SAF1 practices. A web resource can have one view (page) or ten. A wizard can have ten pages defined, but it can use only 3 or 5 of them depending on current state and transitions. It is better to think in terms of web resources, and when it goes out of scope. A wizard is a distinct web resource, who cares how many pages it has. I have built a wizard engine a year ago, and it proved its viability and robustness. No XML, by the way. Check the [http://www.superinterface.com/wizard/signupWizard.do sample]. Try to break it with Reload, Back and Forward buttons. The wizard code hasn't been changed for almost a year, which shows the maturity. I can provide the code and the docs if there is interest. I know that Tim as well as Jason dislike session-scoped data. I hope you guys change your point of view. + * [MJ] In regards to wizards and Redirect-After-Post pattern, does Webwork have something like FlashScope? FlashScope works for only one redirect call, so there may be something longer than FlashScope, but shorter than session. At best, it would be great if a stateful component like a wizard, could be assigned to its own FlashScope+ . 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots
--
* [jcarreira] You had me until the abstract class bit... Does it have to
be abstract? Also, this limits testability in not-ok-ways...
* [crazybob] It only has to be abstract if you want your action to be
able to call methods on the mixin without casting. If it doesn't need to call
those methods, there's no need for your action to explicitly implement that
interface. You could also say `((ValidationAware) this).addActionError()`. I
personally don't mind making the action abstract. In IntelliJ, you just make a
mock class that extends your action and it will automatically generate stubs
for the methods.
* [plightbo] As mentioned earlier, you might be able to do this by using
the value stack. For example, you could stick in a single ValidationSupport
object at the bottom of the stack and then all classes would add error messages
there. By adding a simple *Aware interface, actions could get a handle to that
for adding error messages.
-
- * [jcarreira] Very nice idea... +1 ... We already do something like that.
There's always a default TextProvider pushed onto the bottom of the stack for
getting default texts... makes localized texts work with Sitemesh, for
instance, when you're not hitting an action. Of course, that will be a problem
when we're not using ThreadLocals.
+ * [jcarreira] Very nice idea... +1 ... We already do something like that.
There's always a default TextProvider pushed onto the bottom of the stack for
getting default texts... makes localized texts work with Sitemesh, for
instance, when you're not hitting an action. Of course, that will be a problem
when we're not using ThreadLocals.
+ * [tm_jee] What about keeping ActionSupport but instead have an
AbstractActionSupport which ActionSupport extends off which consisting of
getter/setters for the plugable strategy (like setValidatable(...)
setValidationAware(...) setTextProvider(...) etc). There will be a default for
those if none is set. We could then wired them in through Spring since Sprinc
is now the recommended IOC container.
+
1. [molitor]Extends support on actions in xml (Configuration Inheritance).
Occasionally I want to utilize an existing action but only change one
parameter. It would be nice to do something as simple as.{{{action
name=addPerson class=com.opensymphony.webwork.showcase.person.AddPerson
interceptor-ref name=validationStack/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- /action}}}I'd prefer using this approach instead of having the xmlAction chain to another. 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. + [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) == What JDK Version? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- action name=xmlAddPerson extends=addPerson result name=inputxmlAddPerson.jsp/result /action}}}I'd prefer using this approach instead of having the xmlAction chain to another. + * [tm_jee] Sounds cool. It would probably be an overkill to extend this idea into the interceptor as well, wouldn't it. 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. - [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) + * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) == What JDK Version? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] A new instance per action configuration, right? Not per-invocation... * [crazybob] Last I tested it was per invocation (I remember because it surprised me). This is actually a non-issue. We'll create a custom `ConfigurationProvider` for Struts which won't have this problem. * [plightbo] Agreed, by abstracting most configuration out, we can control the lifecycle. I think the lifecycle should be either once per interceptor or once per invocation. Currently the implementation is too cumbersome (once per unique action configuration). + * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over). @@ -99, +100 @@ to write applications that work for portlets too? I would hope that we all work towards a world where direct access to the underlying servlet API objects is considered an anti-pattern. * [crazybob] Another good point. + 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. @@ -111, +113 @@ * [crazybob] Does specified == documented? Can you elaborate on easily knowing when you're done and why we can't address that use case with one interface? We should expose the user to one interface: `Invocation`. We can have as many objects as we like when it comes to the internal implementation. * [plightbo] Big +1. I would add the ValueStack to this list as well. Let's have one object for each invocation, and also make sub invocations (chaining or ww:action calls) a first class citizen through child/parent invocation relationships. * [jcarreira] Let's have an interactive design session on this... I'm not sure it's as easy as you think to merge them all into one (although behind one interface should be doable). + * [tm_jee] Sorry, I don't get this bit. :-P We could just expose ActionInvocation. ActionProxy could be obtained from ActionInvocation. Or maybe just expose ActionProxy's method in ActionInvocation, but actually its just delegating to ActionProxy. Did I miss something? 1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe we should have two methods? `getResult()` and `getFinalResult()`. Is there a good use case for this? @@ -129, +132 @@ * [mrdon] I dunno, are you planning to make protected getters/setters for every field? I've found protected fields to be invaluable when extending frameworks (again, subscribing to the believe we should let the user do what they want and not artifically restrict them). I do wish you could declare the fields _only_ available to subclasses and not to the whole package. * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access if need be, change the underlying implementation, manage thread safety, protect our own code against unexpected conditions/states, etc. Fields are OK within a package, but when it comes to public APIs, better safe than sorry a year from now. * [jcarreira] Oops, I was translating fields - properties and thinking of getters and setters. + * [tm_jee] I am kindof thinking in the same line as Don. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -140, +144 @@ * [plightbo] The name doesn't bother me, but the implementation is far too complex. I would propose we cut it down from all the crazy package/interface/model-driven stuff we have now to a simple i18n RB loading approach that uses 0 or more global bundles as well as bundles associated with the _view_ (NOT the action, since that never made much sense). * [mrdon] I'd like to see this re-evaluated as well. For one, I want to make it easier to provide an impl that gets messages from a Struts bundle, which really isn't possible now. * [jcarreira] +1 to simplifying. We started with lots of separate resource bundles for per-action texts, but we're moving to one resource bundle per module. It's too much hassle. + * [tm_jee] I like the feature WebWork has that allows resource bundle to be overriden at different levels through inheritance hierarchy, package hierarchy and a global level. If possible, please keep them. :-) 1.
[Struts Wiki] Update of RoughSpots by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- 1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much sense until the interceptor lifecycle is specified (see next item). I've never needed them, yet it's a pain to implement empty methods every time I implement an interceptor. Users can use the constructor/finalizer or we can create additional lifecycle interfaces. * [plightbo] I don't really care. This ties more in to the next item... + * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. 1. Specify `Interceptor` lifecycle. Right now if we apply an interceptor to a single action, we get a new instance every time. If we define an interceptor in a stack, the same instance gets reused. * [jcarreira] A new instance per action configuration, right? Not per-invocation... * [crazybob] Last I tested it was per invocation (I remember because it surprised me). This is actually a non-issue. We'll create a custom `ConfigurationProvider` for Struts which won't have this problem. * [plightbo] Agreed, by abstracting most configuration out, we can control the lifecycle. I think the lifecycle should be either once per interceptor or once per invocation. Currently the implementation is too cumbersome (once per unique action configuration). - * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. + 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsJavaOne2006 by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/StrutsJavaOne2006 New page: What are you going to attend at !JavaOne this year? Current list of Struts happenings and interests. Please add your name to sessions you think you'd like to see. If the session is not listed, please add it. ||'''Tuesday (Apr 16)'''|| || || || ||Times || Event || Location || Who plans to attend? || || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B C|| JM || ||'''Wednesday (Apr 17)'''|| || || || || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || || 5:30 PM - 6:30 PM || Struts BOF || || DB, JM|| || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsJavaOne2006 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsJavaOne2006 -- || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B C|| JM || ||'''Wednesday (Apr 17)'''|| || || || || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || - || 5:30 PM - 6:30 PM || Struts BOF || || DB, JM|| + || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM|| || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsJavaOne2006 by GregReddin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GregReddin: http://wiki.apache.org/struts/StrutsJavaOne2006 -- ||'''Tuesday (Apr 16)'''|| || || || ||Times || Event || Location || Who plans to attend? || - || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B C|| JM || + || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B C|| JM, GR || ||'''Wednesday (Apr 17)'''|| || || || - || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || + || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || ||GR || - || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM|| + || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM, GR|| - || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || + || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM, GR || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by JasonCarreira
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by JasonCarreira: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class that looks at the file as it's uploading to see how big it is on disk * [frankz] Just an opinion, but this seems to me too specific a use case for a framework to encapsulate. I think having an example showing how to do it, perhaps what jcarreira has done at work, would be great, but I for one wouldn't like the framework offering this out of the box... I think it is possible for a framework to be able to do TOO much! * [tm_jee] I think this is pretty use case specific as well, but a progress monitor ui component would be nice. + * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates @@ -280, +281 @@ 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) + * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor - It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one per action. For request scoped resources, take a look at Spring's scoped components. I'm using them at work and they work pretty well (a few issues I'm working through with them notwithstanding). == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. @@ -288, +290 @@ * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). + * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at
[Struts Wiki] Update of RoughSpots by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/RoughSpots -- I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. - * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). - * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. * [jcarreira] I think this is a bad idea, in general. Actions should specify the exact things they need and have them supplied, not just ask for the world (the ActionContext is the world the action lives in). + * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. + - 1. HTML analog tags should stick to HTML attributes. I dont' mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly + 1. HTML analog tags should stick to HTML attributes. I don't mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like actionName, actionAddress, etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + media attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. - * I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? + * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? + * [mrdon] +1 for aligning attributes with HTML attributes 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
param name=namespace/${actionNamespace}/param
/result
}}} My point is this feature enables a new style of development, one closer
to RoR and, IMO, easier for the newbie, without affecting anyone else.
+ * [crazybob] Assuming you have a `getResult()` method and you've defined
a global result, your second example could look like this: {{{
+ result = ActionRedirectResult(bar, foo);
+ return CUSTOM;
+ }}} A Ruby on Rails analog would look like this: {{{
+ public void execute() {
+ ...
+ if (foo) {
+ redirectToAction(foo, bar);
+ }
+ else {
+ forwardToAction(tee);
+ }
+ }
+ }}} If the user doesn't call a result method, we would use an intelligent
default. You could implement this using an interceptor and an action support
class. However, I'm with Jason: I've never needed this and I like the
seperation.
== Nice to haves ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + + 1. Do we want to keep `ModelDriven`? + + 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. + + 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/RoughSpots -- 1. Do we want to keep `ModelDriven`? 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. + * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? + * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic Environment api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic Environment api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. + + 1. Add action and method attributes to the submit button tag so users don't have to know about the action:Name and method:name conventions. == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) 1. Do we want to keep `ModelDriven`? + * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -291, +292 @@ 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) - * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor - It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one per action. For request scoped resources, take a look at Spring's scoped components. I'm using them at work and they work pretty well (a few issues I'm working through with them notwithstanding). + * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor - It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one
[Struts Wiki] Update of RoughSpots by Eric Molitor
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Eric Molitor: http://wiki.apache.org/struts/RoughSpots -- result name=inputxmlAddPerson.jsp/result /action}}}I'd prefer using this approach instead of having the xmlAction chain to another. * [tm_jee] Sounds cool. It would probably be an overkill to extend this idea into the interceptor as well, wouldn't it. + * [molitor] Agree, falls on the short side of the 80/20 rule 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FrontPage by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/FrontPage -- * [StrutsMoreAboutJSF] -- JSF vs. Struts (Is this still relevant?) * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion + * [SAF1RoughSpots] -- what can be improved in Struts 1.x * SetupItems -- Struts extension to better handle dropdown list setup * AjaxStruts -- Ajax using XMLHttpRequest and Struts * StandaloneTiles -- Ideas how to separate Tiles from Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Action1RoughSpots by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/Action1RoughSpots New page: The purpose of this page is for people, anyone, to post their thoughts on what they would like to see happen in Struts Action1 framework (that is, the non-Webwork, non-Shale version of Struts). As the name implies, it should be a list of current rough spots. * '''Per-request Action instantiation''' [FrankZ] Actions should be instantiated for each request, therefore removing the thread safety concerns that exist today. * '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm should not need to extend !ActionForm. The framework would have to be smart enough to not call validate() and such in that case. This would allow for the Action to be the !ActionForm as well, and this is really the underlying goal because many people view them being separate as a rough spot. * '''Built-in AJAX support''' [FrankZ] I am not entirely sure what the best form for this is, although I believe the !AjaxTags paradigm still has a great deal of merit. In any case, in today's world, not offering some degree of AJAX out of the box is probably a rough spot for many. * '''Custom attributes on tags''' [FrankZ] All Struts tags that render HTML should allow for arbitrary attributes. I again propose a specCompliant attribute on the html:html tag. When true, no arbitrary attributes are allowed (this would be the default if the attribute is not present). If false, any attribute can be added. This has been a hassle for me a couple of times where I wanted to store some custom information on a tag for client-side purposes. * '''The ability to switch off auto-form population''' [FrankZ] The idea here is that Struts would still instantiate an !ActionForm and call reset(), but that's it. This can be useful if you want to use an !ActionForm only as an output object, but want to handle input manually. This came up for me converting a non-Struts app to Struts, where there was no notion of an !ActionForm in the previous framework. * '''Built-in dependency injection''' [FrankZ] This should be modeled after what is offered in JSF. If we took the code from the !DependencyFilter in Java Web Parts, added in true injection (shouldn't be a terribly big deal), I believe we would have even better capabilities than in JSF. Spring is of course still out there for those that need/want more! This may not be so much a rough spot as just a fairly low-hanging piece of fruit (because most of the work is already done by virtue of leveraging !DependencyFilter) that I think people would appreciate having. * '''!ThreadLocal !ActionContext''' [FrankZ] Yes, I think this is one place we should flat-out rip off Webwork :) Backwards-compatibility would have to be considered, but I'd like Actions to have to deal with a single object, and for that object to be accessible via the !ThreadLocal mechanism. This should also open the door for POJO Actions. * '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. * '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by DonBrown
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
--
The Cactus tests for Struts Taglib are located in the
action/integration/taglib-it module. To run the tests, you must provide a
value for the 'cargo.tomcat5x.home' System property, for example:
{{{
-~/svn/struts/current/action/integration
+~/svn/struts/current/action/integration/taglib-it
$ mvn -P perform-itest -Dcargo.tomcat5x.home=c:/java/apache-tomcat-5.5.16
}}}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (./) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. @@ -61, +61 @@ || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || - || Commons Validator || 1.2.0 || Released || Struts Validator || + || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || == Testing Checklist == @@ -69, +69 @@ === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || All fail || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || - || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || _ || + || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || N/A || - || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || _ || + || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || N/A || - || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || _ || + || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || N/A || - || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || _ || + || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || N/A || == Test Build Checklist (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Added the server for apache-site -- usernameyourid/username privateKey/path/to/private/key/privateKey /server +server + idapache-site/id + usernameyourid/username + privateKey/path/to/private/key/privateKey +/server /servers profiles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- To help everyone get started with Struts Action 1.3.2 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.2 distribution from http://svn.apache.org/dist/struts/action/v1.3.2/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) - * Extract the distribution to a likely location (\opt\struts-action-1.3.2) + * Extract the distribution to a likely location (/opt/struts-action-1.3.2) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat @@ -88, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit -SNAPSHOT || || + || A0. || Update all pom.xml files to omit -SNAPSHOT || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ and user@ lists || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || (./) || - || A7. || Post release-quality vote on dev@ and user@ lists || || + || A7. || Post release-quality vote on dev@ and user@ lists || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of StrutsReleasePlans by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsReleasePlans -- * StrutsTaglibRelease131 - ''Struts Taglib Version 1.3.1'' (cancelled) * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' + * StrutsActionRelease133 - ''Struts Action Version 1.3.3'' == 1.2.x == * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease133 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease133 New page: = Struts Action 1.3.3 Release = == Info == 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases] 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines] == Release Manager == The release manager is '''Don Brown''' == How to Help == Everyone in the Struts community, users, developers, and committers, is encouraged to test a release, report any issues, and post to dev@ any comments on the overall quality of the release. To help everyone get started with Struts Action 1.3.3 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.3 distribution from http://svn.apache.org/dist/struts/action/v1.3.3/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) * Extract the distribution to a likely location (/opt/struts-action-1.3.3) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., /opt/struts-action-1.3.3/src) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21710 == TO DO == == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list || || || 2. || Review/Resolve Outstanding Bugs || || || 3. || Update Release Notes || || || 4. || Check Dependencies || || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release Guidelines] is a helpful overall process backgrounder, but HTTPD does not use a test-build stage. External Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || || || 2. || Run Cactus Tests (see below) || || || 3. || Play test examples application (TC 5.0.x) || || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || || || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || || || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || || || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || || == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || || A5. || Update all pom.xml files to 1.3.4-SNAPSHOT || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ and user@ lists || || == Vote (A) == || PMC Member || Quality || Voting thread is _ If release vote fails, including for a lack of quorum, remove from dist folder. == Point Release Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions [2]
[Struts Wiki] Trivial Update of StrutsActionRelease133 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease133 -- == Release Manager == - The release manager is '''Don Brown''' + The release manager is '''Wendy Smoak''' == How to Help == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || - || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || || + || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || (./) || || A7. || Post release-quality vote on dev@ and user@ lists || (./) || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMavenRelease by JamesMitchell
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by JamesMitchell:
http://wiki.apache.org/struts/StrutsMavenRelease
The comment on the change is:
make the version a bit generic
--
== 1. Releasing Struts Action ==
- 1. Create the new directory on cvs.apache.org, for example
cvs.apache.org/dist/struts/action/v1.3.2
+ 1. Create the new directory on cvs.apache.org, for example
cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x')
1. Ensure that your settings.xml contains a server for
apache-maven-test-builds (see the Suggested Settings section on
StrutsMaintenanceMaven)
1. Clear out your local Maven repo
1. Build all jar and war artifacts, including -sources and -javadoc, and
deploy them to maven-snapshot-repository.
@@ -21, +21 @@
{may have to deploy the site for each module individually}
cd assembly
mvn assembly:assembly
- scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.2
+ scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.x
}}}
== 2. Releasing the struts-parent pom ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of StrutsMavenRelease by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMavenRelease
--
{may have to deploy the site for each module individually}
cd assembly
mvn assembly:assembly
- scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.x
+ scp target/assembly/out/*
people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x
}}}
== 2. Releasing the struts-parent pom ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- 1. Allow indexable parameters similar to how it works in struts (with indexed=true) but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. - * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsReleasePlans by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsReleasePlans -- '''NOTE''' For info on cutting a release see [http://struts.apache.org/releases.html#Releases Struts Release Guidelines] and StrutsMavenRelease. - = 1. Struts Action 1.3.x Release Plans = - + = 1. Struts Action = + == 1.3.x == * StrutsClassicRelease130 - ''Struts Version 1.3.0'' * StrutsActionRelease131 - ''Struts Action Version 1.3.1'' * StrutsTaglibRelease131 - ''Struts Taglib Version 1.3.1'' (cancelled) * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' + == 1.2.x == - - = 2. Struts-Faces Release Plans = - - * StrutsFacesRelease101 - ''Struts-Faces Version 1.0.1'' - - = 3. Struts Action 1.2.x Release Plans = - * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' * StrutsRelease124 - ''Struts Version 1.2.4'' @@ -28, +22 @@ * StrutsRelease127 - ''Struts Version 1.2.7'' * StrutsRelease128 - ''Struts Version 1.2.8'' * StrutsRelease129 - ''Struts Version 1.2.9'' + == Miscellaneous == + * StrutsFacesRelease101 - ''Struts-Faces Version 1.0.1'' + * StrutsScriptingRelease100 - ''Struts Scripting Version 1.0.0'' + * StrutsScriptingRelease101 - ''Struts Scripting Version 1.0.1'' - = 4. Struts Shale Release Plans = + = 2. Struts Shale = * ShaleRelease100 - ''Struts Shale Version 1.0.0'' * ShaleRelease101 - ''Struts Shale Version 1.0.1'' * ShaleRelease102 - ''Struts Shale Version 1.0.2'' - = 5. Struts Scripting Release Plans = - - * StrutsScriptingRelease100 - ''Struts Scripting Version 1.0.0'' - * StrutsScriptingRelease101 - ''Struts Scripting Version 1.0.1'' - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 New page: = Struts Action 1.3.2 Release = == Info == 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases] 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines] == Release Manager == The release manager is '''Don Brown''' == How to Help == Everyone in the Struts community, users, developers, and committers, is encouraged to test a release, report any issues, and post to dev@ any comments on the overall quality of the release. To help everyone get started with Struts Action 1.3.2 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.2 distribution from http://svn.apache.org/dist/struts/action/v1.3.2/ (when it is available) * Extract the distribution to a likely location (\opt\struts-action-1.3.2) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat * * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., \opt\struts-action-1.3.2) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, see if they are known issues by comparing your log with ours at http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/ == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21699 == TO DO == == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list || || || 2. || Review/Resolve Outstanding Bugs || || || 3. || Update Release Notes || || || 4. || Check Dependencies || || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the beta/release-candidate/final process. Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release Guidelines] is a helpful overall process backgrounder, but HTTPD does not use a test-build stage. External Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.2.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || || || 2. || Run Cactus Tests (see below) || || || 3. || Play test examples application (TC 5.0.x) || || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || _ || || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || _ || || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || _ || || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || _ || == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A0. || Update action and build, project.xml and pom.xml to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_1, STRUTS_BUILD_1_3_1 || || || A1.1 || Modify svn:externals for 'build' on STRUTS_ACTION_1_3_1 tag || || || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || || A3. || Update action and build, project.xml and pom.xml to 1.3.2-SNAPSHOT || || || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.1 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || Post release-quality vote on dev@ and user@ lists || || == Vote (A) == || PMC Member || Quality || Voting thread is _ If release vote fails, including for a lack of quorum, remove from dist folder. == Point Release Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions [2] || || || B2. || Create a new JIRA version level (1.3.3) || || || B3. || Update Acquiring page on website and Test Downloads || || == Vote (B) == || PMC Member || Quality
[Struts Wiki] Update of StrutsActionRelease132 by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update action and build, project.xml and pom.xml to omit -SNAPSHOT || || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_1, STRUTS_BUILD_1_3_1 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || - || A1.1 || Modify svn:externals for 'build' on STRUTS_ACTION_1_3_1 tag || || || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || - || A3. || Update action and build, project.xml and pom.xml to 1.3.2-SNAPSHOT || || + || A3. || Update action and build, pom.xml to 1.3.3-SNAPSHOT || || - || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.1 || || + || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || Post release-quality vote on dev@ and user@ lists || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: The Maven 1 logs (even if there were any) will look nothing like Maven 2 logs -- * Change to the new folder (e.g., \opt\struts-action-1.3.2) * $ mvn * Wait about five minutes for Maven to download and build everything - ** If you see any error messages, see if they are known issues by comparing your log with ours at http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/ + ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. == Outstanding Bugs == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Update checklists, add link to snapshot. -- To help everyone get started with Struts Action 1.3.2 (when it is available), here are the simplest installation instructions that can possibly work: - * Download the Struts 1.3.2 distribution from http://svn.apache.org/dist/struts/action/v1.3.2/ (when it is available) + * Download the Struts 1.3.2 distribution from http://svn.apache.org/dist/struts/action/v1.3.2/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) * Extract the distribution to a likely location (\opt\struts-action-1.3.2) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat - * * http://wiki.apache.org/struts/StrutsMaintenanceMaven + * http://wiki.apache.org/struts/StrutsMaintenanceMaven - * Change to the new folder (e.g., \opt\struts-action-1.3.2) + * Change to the new folder (e.g., /opt/struts-action-1.3.2/src) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. @@ -88, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update action and build, project.xml and pom.xml to omit -SNAPSHOT || || + || A0. || Update all pom.xml files to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || - || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || - || A3. || Update action and build, pom.xml to 1.3.3-SNAPSHOT || || + || A3. || Update all pom.xml files to 1.3.3-SNAPSHOT || || || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || Post release-quality vote on dev@ and user@ lists || || @@ -110, +110 @@ || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions [2] || || - || B2. || Create a new JIRA version level (1.3.3) || || + || B2. || Create a new JIRA version level (1.3.2) || || || B3. || Update Acquiring page on website and Test Downloads || || == Vote (B) == @@ -124, +124 @@ || '''#''' || '''Description''' || '''Completed''' || || C1. || Copy Distribution to Mirrored Directories [3] || _ || - || C2. || Deploy JAR and POM to Apache Java-Repository || _ || + || C2. || Promote Test Build from maven-snapshot-repository to dist/maven-repository || _ || || C3. || After 24 hours, update Acquiring page on website || _ || || C4. || Post an announcement to lists and website || _ || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsActionRelease132 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Updated test build checklist -- || A0. || Update all pom.xml files to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || - || A3. || Update all pom.xml files to 1.3.3-SNAPSHOT || || + || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || || - || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || - || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || - || A6. || Post release-quality vote on dev@ and user@ lists || || + || A7. || Post release-quality vote on dev@ and user@ lists || || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- with annotations instead. For a detailed example, take a look at how Shale's Tiger Extensions package lets you get the functionality of a ViewController interface without having to say implements ViewController in your action class. + * [crazybob] +1 for keeping the `Action` interface--it enforces that `execute()` is the default method. 1. Only put classes in root package that most users need to know about. For example, most don't need to know about `Default*` or `ObjectFactory`. * [plightbo] +1 on this - sounds like Bob has a good handle on what it takes to make a nice API. I'll defer to him on this. @@ -38, +39 @@ subtlety here to take into account -- there is a difference between APIs that application developers should depend on versus those extending the framework should be allowed to extend. The latter category of folks can be presumed to be smaller, as well as more willing to deal with occastional API breakages. + * [crazybob] +1 for impl package naming convention. I think we should focus on the application developer API for the initial release and then introduce a more featureful extension API in a later release. 1. Only make classes/members public if we're willing to guarantee future compatibility. Everything else should be package-private or excluded from the Javadocs. @@ -89, +91 @@ you are in exactly the same boat. The Servlet API considers this a feature rather than a bug, because a Filter can actually wrap the incoming request and response objects to provide extra functionality -- this at least wouldn't be possible in the case of a thread-local state object. + * [crazybob] Good point (Though it is possible with a thread local API. Your code can set the thread local to your wrapped object and then restore the original object in a finally block. Not ideal.) * [craigmcc] Interceptors need access to the servlet API -- doesn't anyone care about making it possible to write applications that work for portlets too? I would hope that we all work towards a world where direct access to the underlying servlet API objects is considered an anti-pattern. + * [crazybob] Another good point. 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. @@ -143, +147 @@ * [jcarreira] I think it's great that you want to take the HTTP spec at its word... most users don't care though. * [crazybob] I'm not arguing semantics. There are real security implications to using GET when you should use POST, not to mention products like Google Web Accelerator will reak havok on your site. As framework developers, we should make using POST as easy as GET for users. To not help users do the right thing in this situation would be irresponsible, and not in the letter of the law sense. * [frankz] Perhaps a new attribute on the action mapping? type=view or type=update? This would really make the mapping of a specific various type, not the underlying Action, which might be better because the type is abstracted from the actual implementation and the Action class itself can house both types of functions (i.e., something like a !DispatchAction), but the framework can know to treat them differently as appropriate. I'm not one of those no XML config! folks, I actually still prefer it to annotations, but having an analogous annotation would be a good idea too. + * [crazybob] In addition to view and update, we might want chained view and chained update. Can anyone else think of more stereotypes? Can you think of a better name than stereotype? Strategy? 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. We could rename these `#request` for request parameters and `#requestAttributes` for request attributes. @@ -178, +183 @@ 1. Enable Java package import in configuration so you don't have to repeat the same package name over and over (like WW1 does). * [jcarreira] +1 if it can be made sane... It can get confusing. It also makes tool support worse (i.e. IDEA can find it as a fully qualified class name) + * [crazybob] Regarding tool support, I like writing less code, and this doesn't preclude using fully qualified class names if you still want to. Hopefully this new exposure will bring us real tool support and this won't be an issue. 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax for validation is trivial and not that impressive, but people are going to want to do real ajax work, and
[Struts Wiki] Trivial Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. - * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` which pulls an object of the session and passed it to your action. Or you can use Spring. + * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. @@ -313, +313 @@ * [martinc] The big issue with the JDK version is app servers. This comes in two parts. First is whether all of the major app server vendors have products available that support the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue is customer acceptance. Enterprise customers, especially, tend to standardise on their app server, and they are not quick to upgrade. Unless the application vendor has a great deal of influence over the customer's infrastructure, the vendor has to live with whatever app server version is in use at the customer site. It is rare, then, that the application vendor can dictate the JDK version. On the other hand, the customer usually couldn't care less what version of Struts the application was built with. * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. - * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support drive design decisions. + * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too.
[Struts Wiki] Update of RoughSpots by GeorgeDinwiddie
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GeorgeDinwiddie: http://wiki.apache.org/struts/RoughSpots -- * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. +* [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. -* [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/RoughSpots -- 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you want to return anything that requires more than the symbol, you have to do some less than intuitive things to make the Action and the Result cooperate. I'd prefer to see a concrete Result get returned from Action methods, which would allows developers to do more powerful things more easily. There are a bunch of ways to make it backward compatible too. You could return 'new SymbolicResult(success)' and have the SymbolicResult do the lookup stuff (You could even redefine the String constants to be SymbolicResults). You could alternatively use a static class to do Results.find(SUCCESS). Or you could even allow method to continue to return String or Result, and if String wrap it in a SymbolicResult. * [frankz] +1. This is one area where I personally think Struts had it right and we've seen frameworks getting it wrong subsequently. !ActionForward I believe is the right concept, even if the realization might not be optimal. I think the difference between return ok; and return new ActionResult(ok); is pretty minimal, but the later opens up a lot of possibilities being a true object that can have behaviors and properties and such. * [crazybob] There's no reason we can't support both `String` and `Result` return types for action methods. I think we should encourage `String` though. Can you provide some example use cases for when `String` isn't enough? + * [frankz] A few that come to mind... the ability to choose between redirect and forward based on decisions made in code (you could argue that you can have two result's defined, one with type redirect and one with type forward, but then that starts to clutter the config file I think)... the ability to add parameters to a forwarded result (i.e., if you wanted to forward to another action, how can you add parameters just by returning a String? Well, unless the processor expects and can deal with a query string appended I support)... the ability to add an anchor name to the response... the opportunity to include additional objects in the response (i.e., what if you had some sort of ViewSupport object that the presentation can make use of... it might be more intuitive to add it to a Result than to directly add it as a request attribute, and that also makes for better abstraction from the servlet API). I'm sure there's more, and I'm sure there are ways to accomplish most of these things without returning an object, but I think the clarity of the resultant code is greater by returning a Result object, and it opens up possibilities I can't think of (i.e., functionality encapsulated in that object independant of tbe interceptor stack). == Nice to haves == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by DonBrown
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by DonBrown:
http://wiki.apache.org/struts/RoughSpots
--
* [frankz] +1. This is one area where I personally think Struts had it
right and we've seen frameworks getting it wrong subsequently.
!ActionForward I believe is the right concept, even if the realization might
not be optimal. I think the difference between return ok; and return new
ActionResult(ok); is pretty minimal, but the later opens up a lot of
possibilities being a true object that can have behaviors and properties and
such.
* [crazybob] There's no reason we can't support both `String` and
`Result` return types for action methods. I think we should encourage `String`
though. Can you provide some example use cases for when `String` isn't enough?
* [frankz] A few that come to mind... the ability to choose between
redirect and forward based on decisions made in code (you could argue that you
can have two result's defined, one with type redirect and one with type
forward, but then that starts to clutter the config file I think)... the
ability to add parameters to a forwarded result (i.e., if you wanted to forward
to another action, how can you add parameters just by returning a String?
Well, unless the processor expects and can deal with a query string appended I
support)... the ability to add an anchor name to the response... the
opportunity to include additional objects in the response (i.e., what if you
had some sort of ViewSupport object that the presentation can make use of... it
might be more intuitive to add it to a Result than to directly add it as a
request attribute, and that also makes for better abstraction from the servlet
API). I'm sure there's more, and I'm sure there are ways to accomplish most
of these things without returning an object, but I think the clarity of the
resultant code is greater by returning a Result object, and it opens up
possibilities I can't think of (i.e., functionality encapsulated in that object
independant of tbe interceptor stack).
-
+ * [mrdon] For further reading:
http://forums.opensymphony.com/thread.jspa?threadID=23621tstart=45
== Nice to haves ==
1. Inheritance is not a good way to reuse code between actions. One work
around is to use the strategy pattern to swap in different implementations of
interfaces like `ValidationAware`. It would be nice if the framework had
built-in support for mixins using cglib or Dynaop. For example, instead of
extending a class that implements `ValidationAware`, SAF could extend an action
class at runtime and implement the `ValidationAware` methods by delegating them
to another object (a mixin): {{{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
