date:20060424

Author: wsmoak
Date: Mon Apr 24 00:03:39 2006
New Revision: 396463

URL: http://svn.apache.org/viewcvs?rev=396463&view=rev
Log:
Correct the package name.
Added svn eol-style property to scripts.

Modified:

struts/action/trunk/apps/scripting-mailreader/src/main/java/org/apache/struts/apps/scriptingmailreader/Constants.java
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/Error.jsp

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditSubscription.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/Locale.gv
   (props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/Logoff.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/Logon.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/SaveRegistration.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/SaveSubscription.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/Welcome.gv
   (contents, props changed)

struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/struts-config.xml

Modified: 
struts/action/trunk/apps/scripting-mailreader/src/main/java/org/apache/struts/apps/scriptingmailreader/Constants.java
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/scripting-mailreader/src/main/java/org/apache/struts/apps/scriptingmailreader/Constants.java?rev=396463&r1=396462&r2=396463&view=diff
==
--- 
struts/action/trunk/apps/scripting-mailreader/src/main/java/org/apache/struts/apps/scriptingmailreader/Constants.java
 (original)
+++ 
struts/action/trunk/apps/scripting-mailreader/src/main/java/org/apache/struts/apps/scriptingmailreader/Constants.java
 Mon Apr 24 00:03:39 2006
@@ -88,7 +88,7 @@
  * The package name for this application.
  * 
  */
-public static final String PACKAGE = "org.apache.struts.apps.mailreader";
+public static final String PACKAGE = 
"org.apache.struts.apps.scriptingmailreader";
 
 /**
  * 

Modified: 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/Error.jsp
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/scripting-mailreader/src/main/webapp/Error.jsp?rev=396463&r1=396462&r2=396463&view=diff
==
--- struts/action/trunk/apps/scripting-mailreader/src/main/webapp/Error.jsp 
(original)
+++ struts/action/trunk/apps/scripting-mailreader/src/main/webapp/Error.jsp Mon 
Apr 24 00:03:39 2006
@@ -22,7 +22,7 @@
 
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <%@ page import="org.apache.struts.Globals" %>
-<%@ page import="org.apache.struts.apps.mailreader.Constants" %>
+<%@ page import="org.apache.struts.apps.scriptingmailreader.Constants" %>
 
 <%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
 <%@ taglib uri="http://struts.apache.org/tags-html"; prefix="html" %>

Modified: 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv?rev=396463&r1=396462&r2=396463&view=diff
==
--- 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv
 (original)
+++ 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv
 Mon Apr 24 00:03:39 2006
@@ -1,7 +1,7 @@
 import java.lang.reflect.InvocationTargetException;
 import javax.servlet.ServletException;
 import org.apache.commons.beanutils.PropertyUtils;
-import org.apache.struts.apps.mailreader.*;
+import org.apache.struts.apps.scriptingmailreader.*;
 import org.apache.struts.apps.mailreader.dao.*;
 
 act = request.getParameter("task");

Propchange: 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditRegistration.gv
--
svn:eol-style = native

Modified: 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditSubscription.gv
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/scripts/EditSubscription.gv?rev=396463&r1=396462&r2=396463&view=diff
==
--- 
struts/action/trunk/apps/scripting-mailreader/src/main/webapp/WEB-INF/s

[jira] Updated: (STR-2838) Add necessary reports to site build

2006-04-24 Thread Don Brown (JIRA)

 [ http://issues.apache.org/struts/browse/STR-2838?page=all ]

Don Brown updated STR-2838:
---

Fix Version: 1.3.2
Version: (was: 1.3.2)

> Add necessary reports to site build
> ---
>
>  Key: STR-2838
>  URL: http://issues.apache.org/struts/browse/STR-2838
>  Project: Struts Action 1
> Type: Bug

>   Components: Infrastructure
> Reporter: Don Brown
> Assignee: Don Brown
>  Fix For: 1.3.2

>
> We need to fix the website/docs build so that we can update the website 
> easily.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396466 - /struts/action/trunk/pom.xml

Author: wsmoak
Date: Mon Apr 24 00:11:50 2006
New Revision: 396466

URL: http://svn.apache.org/viewcvs?rev=396466&view=rev
Log:
Add tiles to the list of modules.

Modified:
struts/action/trunk/pom.xml

Modified: struts/action/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/pom.xml?rev=396466&r1=396465&r2=396466&view=diff
==
--- struts/action/trunk/pom.xml (original)
+++ struts/action/trunk/pom.xml Mon Apr 24 00:11:50 2006
@@ -68,6 +68,7 @@
 el
 extras
 taglib
+tiles
 faces
 scripting
 apps



-
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=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10121&fixfor=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 M

[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]

svn commit: r396468 - /struts/action/trunk/tiles/pom.xml

Author: wsmoak
Date: Mon Apr 24 00:25:54 2006
New Revision: 396468

URL: http://svn.apache.org/viewcvs?rev=396468&view=rev
Log:
Corrected the project name.

Modified:
struts/action/trunk/tiles/pom.xml

Modified: struts/action/trunk/tiles/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/tiles/pom.xml?rev=396468&r1=396467&r2=396468&view=diff
==
--- struts/action/trunk/tiles/pom.xml (original)
+++ struts/action/trunk/tiles/pom.xml Mon Apr 24 00:25:54 2006
@@ -33,7 +33,7 @@
 
struts-tiles
jar
-   Struts Tiles
+   Struts Action - Tiles


   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396472 - /struts/action/trunk/apps/faces-example1/pom.xml

Author: wsmoak
Date: Mon Apr 24 00:39:12 2006
New Revision: 396472

URL: http://svn.apache.org/viewcvs?rev=396472&view=rev
Log:
Added the myfaces-jsf-api dependency, which was marked as 'provided' in the 
struts-faces pom.

Modified:
struts/action/trunk/apps/faces-example1/pom.xml

Modified: struts/action/trunk/apps/faces-example1/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/faces-example1/pom.xml?rev=396472&r1=396471&r2=396472&view=diff
==
--- struts/action/trunk/apps/faces-example1/pom.xml (original)
+++ struts/action/trunk/apps/faces-example1/pom.xml Mon Apr 24 00:39:12 2006
@@ -19,18 +19,6 @@
  */
 -->
 
-
-
 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/maven-v4_0_0.xsd";>
 
@@ -68,6 +56,12 @@
 myfaces-extensions
 1.0.9
   
+  
+myfaces
+myfaces-jsf-api
+1.0.9
+ 
+
 





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396474 - /struts/action/trunk/apps/faces-example2/pom.xml

Author: wsmoak
Date: Mon Apr 24 00:50:42 2006
New Revision: 396474

URL: http://svn.apache.org/viewcvs?rev=396474&view=rev
Log:
Added the myfaces-jsf-api dependency, which was marked as 'provided' in the 
struts-faces pom.

Modified:
struts/action/trunk/apps/faces-example2/pom.xml

Modified: struts/action/trunk/apps/faces-example2/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/faces-example2/pom.xml?rev=396474&r1=396473&r2=396474&view=diff
==
--- struts/action/trunk/apps/faces-example2/pom.xml (original)
+++ struts/action/trunk/apps/faces-example2/pom.xml Mon Apr 24 00:50:42 2006
@@ -19,18 +19,6 @@
  */
 -->
 
-
-
 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/maven-v4_0_0.xsd";>
 
@@ -58,6 +46,11 @@
  2.3
  provided
   
+  
+myfaces
+myfaces-jsf-api
+1.0.9
+ 






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bearing down on Struts Action 1.3.2

After a lot of hard work (mostly by Wendy), we have a test release build 
available for testing.  The purpose of this SNAPSHOT build is to get 
some feedback on our new release creation process and general feedback 
for the code.  The key information:


Apache Maven 2 repository - http://cvs.apache.org/maven-snapshot-repository
Struts Action groupId - org.apache.struts.action
Assembly snapshot - 
http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/


This release will be the first with our new Maven 2 build and JIRA bug 
ticket management.  I'm hoping to use JIRA to clearly reflect 
outstanding issues and our general roadmap, rather than relying on 
outstanding bugs listed in the release plan.  Therefore, the new 1.3.2 
release plan:

- http://wiki.apache.org/struts/StrutsActionRelease132

Please take some time and start sifting through our JIRA tickets, 
marking them against their target fix version.  As for the 1.3.2 release 
itself, I'd like to roll it Thursday, so feedback on this snapshot will 
be key to making that release on time.  I'm fully expecting we'll have a 
GA 1.3.x release by JavaOne.


Thanks again Wendy and James!

Don


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (WW-1295) Datepicker doesn't work with swedish locale (with workarounds)

2006-04-24 Thread Peter Westlin (JIRA)

Datepicker doesn't work with swedish locale (with workarounds)
--

 Key: WW-1295
 URL: http://issues.apache.org/struts/browse/WW-1295
 Project: Struts Action 2
Type: Bug

  Components: Views  
Versions: WW 2.2.2
Reporter: Peter Westlin


 just found out why DatePicker doesn't work with swedish locale. It is because 
the file is called calendar-sv.js when it in fact should be calendar-se.js. 
That is, SV instead of SE. 

Two workarounds: 
1) Rename the file in the jar. 
2) If you, like me, are using Maven, solution #1 is really not so nice. Then 
just add 
language="sv" in your JSP's so it looks something like: 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Confluence migration next step: Migrate content

2006-04-24 Thread tm jee

Hey guys,
 
 I've registered myself with the confluence at http://confluence.twdata.org .
 
 Can't seems to see any WebWork related documents there. Is it possible that 
the data haven't been loaded to this instance yet? Or are we suppose to migrate 
it on a page by page basis?
 
 rgds

- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, 24 April, 2006 8:50:02 AM
Subject: [action2] Confluence migration next step: Migrate content

Patrick and I have implemented the first steps of the migration plan:
 - The OpenSymphony WebWork wiki is read-only, save for the project 
developers for rare changes
 - I installed a Confluence instance on my personal server: 
http://confluence.twdata.org
 - Patrick exported the data and loaded it into the new instance

Therefore, we now are at the stage where we need to rename the 
documentation.  The end goal is that we migrate the content to an ASF 
Confluence instance, but until one is available, please work on the 
twdata one so we can at least continue moving forward.

Any user account should be able to edit pages, but if you need admin 
access, let me know.

Again, the server is at http://confluence.twdata.org and everyone please 
join in the effort to migrate its content.  Feel free to add new 
information as well, as this data will be loaded into the ASF instance.

Don

http://confluence.twdata.org  <-- one more time :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396522 - in /struts: current/STATUS.txt site/src/site/fml/helping.fml site/src/site/fml/roadmap.fml site/src/site/site.xml

Author: husted
Date: Mon Apr 24 04:44:53 2006
New Revision: 396522

URL: http://svn.apache.org/viewcvs?rev=396522&view=rev
Log:
Site 
* Update link to issue tracker
FAQs 
* Spell/grammar check
STATUS 
* Note recent Tiles decision and JIRA vote
* Move votes next to board reports for each year 

Modified:
struts/current/STATUS.txt
struts/site/src/site/fml/helping.fml
struts/site/src/site/fml/roadmap.fml
struts/site/src/site/site.xml

Modified: struts/current/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/struts/current/STATUS.txt?rev=396522&r1=396521&r2=396522&view=diff
==
--- struts/current/STATUS.txt (original)
+++ struts/current/STATUS.txt Mon Apr 24 04:44:53 2006
@@ -108,6 +108,47 @@
 
 
 
+2006 PROJECT VOTES AND DECISIONS
+
+Standalone Tiles as TLP 
+* [21 Apr 2006] - "The end goal is a standalone Tiles in the Jakarta Web 
+Commons project (to be created),then Struts Action 1 would have a 
+struts-tiles artifact which makes it possible for Struts users to use 
+this standalone Tiles."
+
+Sean Schofield for PMC
+* [17 Apr 2006] Tally 8 +1 (binding)
+
+Greg Reddin for PMC
+* [15 Apr 2006] Tally 7 +1 (binding)
+
+Multiple User Lists 
+* [24 Mar 2006] Tally 3 +1 (binding), 5 +1 (non-binding); 4 0 (binding); 
+5 -1 (binding);
+
+Struts Shale v1.0.2 Quality
+* [23 Mar 2006] Tally +3 alpha (binding)
+
+Struts Shale v1.0.1 Quality
+* [19 Mar 2006] Tally +1 alpha (binding); -1 alpha (binding)
+
+Struts 1.2.9 Quality
+* [16 Mar 2006] Tally 3 +1 (binding), 2 +1 (non-binding)
+
+Switch to JIRA 
+* [28 Feb 2006] Tally 8 +1 (binding), 1 +1 (non-binding)
+
+Nominate Gary VanMatre as a PMC member
+* [27 Feb 2006] Tally 10 +1
+
+Confirm the Struts Action Library 1.3.0 release plan  
+* [11 Feb 2006] Tally 7 +1 (binding); 3 +1 (non-binding)
+
+Accept WebWork 2 Merger Incubator Proposal  
+* [24 Jan 2006] Tally: 10 +1 (binding); 4 +1 (non-binding)
+
+
+
 2005 BOARD REPORTS
 
 
@@ -200,37 +241,6 @@
 experimental development around a fresh look at web application
 architectures is also taking place in the form of "Shale", a
 JSF-based framework, being proposed as an alternative to Struts 1.x.
-
-
-
-2006 PROJECT VOTES
-
-Sean Schofield for PMC
-* [17 Apr 2006] Tally 8 +1 (binding)
-
-Greg Reddin for PMC
-* [15 Apr 2006] Tally 7 +1 (binding)
-
-Multiple User Lists 
-* [24 Mar 2006] Tally 3 +1 (binding), 5 +1 (non-binding); 4 0 (binding); 5 -1 
(binding);
-
-Struts Shale v1.0.2 Quality
-* [23 Mar 2006] Tally +3 alpha (binding)
-
-Struts Shale v1.0.1 Quality
-* [19 Mar 2006] Tally +1 alpha (binding); -1 alpha (binding)
-
-Struts 1.2.9 Quality
-* [16 Mar 2006] Tally 3 +1 (binding) 2 +1 (non-binding)
-
-Nominate Gary VanMatre as a PMC member
-* [27 Feb 2006] Tally 10 +1
-
-Confirm the Struts Action Library 1.3.0 release plan  
-* [11 Feb 2006] Tally 7 +1 (binding); 3 +1 (non-binding)
-
-Accept WebWork 2 Merger Incubator Proposal  
-* [24 Jan 2006] Tally: 10 +1 (binding); 4 +1 (non-binding)
 
 
 

Modified: struts/site/src/site/fml/helping.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/src/site/fml/helping.fml?rev=396522&r1=396521&r2=396522&view=diff
==
--- struts/site/src/site/fml/helping.fml (original)
+++ struts/site/src/site/fml/helping.fml Mon Apr 24 04:44:53 2006
@@ -70,7 +70,7 @@
 Turbine Mailing
 List about the open source process and the contrast
 between how an
-opensource product and a proprietary product improve
+open source product and a proprietary product improve
 through the user
 community.
 
@@ -254,7 +254,7 @@
 To create a patch, you first have to
 
 checkout
-a copy of the sourcecode or documentation from the main
+a copy of the source code or documentation from the main
 repository.
 You can then change your copy, and create the patch using
 a simple
@@ -575,9 +575,10 @@
 much like it reports
 where a bad programming expression is.
 If it does, then your page should be available under
-target/documentation/.
+target/site/
 
 
+
 
 
 You can also post documentation to the
@@ -775,7 +775,7 @@
 
 Use Bugzilla to
 vote for issues
-you feel should be handle first.
+you feel should be handled first.
 If an issue on your ballot doesn't include a
 patch,
 feel free to try coding one y

svn commit: r396524 - /incubator/webwork2/STATUS.txt

Author: husted
Date: Mon Apr 24 04:53:49 2006
New Revision: 396524

URL: http://svn.apache.org/viewcvs?rev=396524&view=rev
Log:
Update status of JIRA/Confluence and early release. 

Modified:
incubator/webwork2/STATUS.txt

Modified: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=396524&r1=396523&r2=396524&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Apr 24 04:53:49 2006
@@ -14,11 +14,12 @@
 
 * Webwork2/Action2 incubator repository - 
http://svn.apache.org/viewcvs.cgi/incubator/webwork2/
 
-* StrutsAction2 wiki area - http://wiki.apache.org/struts/StrutsAction2
-
 * New Action2 sandbox code - 
https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/
 
-* JIRA instance - http://issues.apache.org/struts
+* JIRA instance - http://issues.apache.org/struts/
+
+* Confluence instance - http://confluence.twdata.org/
+
 
 
 
@@ -29,16 +30,6 @@
 
 
 
-DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
-
-Need to get code grants from all signficant copyright holders of WebWork
-* Don will work with Patrick to contact
-
-
-
-MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
-
-+1 Gabe
 
 MIGRATING FROM ACTION 1 TO ACTION 2 
 
@@ -52,7 +43,7 @@
 * https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/
 
 ** The MailReader application has been ported. Comments and fixes 
-welcome. The "Tour" is next.
+welcome.
 
 ** A new Cookbook application has been started. The suggestion is 
 that we combine the WW Showcase examples and the various Struts 
@@ -73,6 +64,9 @@
 * tag prefix: saf
 * property and configuration files: action
 
+
+* xwork.xml -> struts-action.xml
+
 --
 
 * The Dojo component package was previously 'webwork'.  
@@ -107,21 +101,41 @@
 
 
 
-WIKI DOCUMENTATION
+CONFLUENCE MIGRATION
 
 What do we need to do to register the Snippet macro the ASF SVN?
 
 * http://forums.opensymphony.com/thread.jspa?threadID=24290&tstart=0
 
-For an ongoing Confluence instance, worse case, there's another 
-Confluence installation that we can use, hosted by Contegrix.
+WebWork2 wiki is now readonly. Volunteers may migrate and add content 
+to  at will. Eventually, this content 
+may be transferred directly to a ASF server. 
 
-* http://opensource.atlassian.com/confluence/oss/dashboard.action
+
 
-But,Jeff Turner may be working on getting us a Confluence instance on an ASF 
machine. 
+JIRA MILESTONES
 
+We prefixING the old releases with WW and startING the new releases
+with a numbering scheme only. In this way, old releases will be 
+archived properly and we do not lose the history.
 
 
 
+EARLY RELEASE 
+
+Don and Jason will be hosting a Struts session at JavaOne on May 17. 
+It would be helpful if a tagged build of Action2 were available, 
+even if Action2 is not out of the incubator yet (though it may be).
+
+Here are some of the things we need to do to create a tagged build:
+
+ 1. The tickets gone through, keeping only essential tickets against this next 
release (2.0.0)
+ 2. Ensuring the project renaming is complete in a files, including source 
code comments
+ 3. Renaming WW instances on the wiki docs (once we get something stood up)
+ 4. Testing some of the new changes like the date picker, rich text editor, 
and tooltips
+
+The general release process is described here:
+
+* http://struts.apache.org/releases.html
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Ted Husted

On the RoughSpots page,

* http://wiki.apache.org/struts/RoughSpots

there's a reference to Action 3.x that speaks as if it's far away.
That doesn't need to be the case. We can create a branch for "Action
Next" or "Ti2" as soon as the code comes down from the incubator. We
did the same for Action 1.2 and Action 1.3. We've continued to
maintain and extend Action 1.2, while more agressive changes where
made to Action 1.3.

The original proposal was for Ti to happen in two phases. The first
phase was to release Action 2.0 based on WebWork 2.2 by making only
necessary and prudent changes. More aggressive changes were to happen
in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
2 might be Action 2.1 or Action 3.x. That's a decision we can make
later.

Personally, I don't believe the release of Action 2.0 is going to
create a migration stampede. Some people who are starting new projects
may decide to use Action 2 instead of Action 1. But the people I know
won't bother to migrate existing applications. At least not anytime
soon.

Right now, some teams that are looking forward to Action 2 are getting
started with WebWork 2.2 now. I suggest that Job One should be to get
a current release out there that we can use while we work on Phase 2. 
Otherwise, we could easily find ourself maintaining WebWork 2.x at
OpenSymphony and then having to mirror any changes in Action 2.x at
Apache Struts.

I think it's important to first create a stable release of Action 2.0
as the direct successor to WebWork 2.2, and then focus on the more
aggressive changes slated for Phase 2. We can make it very clear to
people that "Phase 2" is in the works, so people who don't want to
migrate more than once can make an informed decision.

Thoughts?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread netsql


Is SAF2 CoR based like 1.32 or is that SAF3?

tia,
.V



The original proposal was for Ti to happen in two phases. The first
phase was to release Action 2.0 based on WebWork 2.2 by making only
necessary and prudent changes. More aggressive changes were to happen
in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
2 might be Action 2.1 or Action 3.x. That's a decision we can make
later.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA cleanup

2006-04-24 Thread David Evans

Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
willing to do this, if its something that a non commiter can do.

dave

On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:
> Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to 
> be exact, that are resolved as "Unresolved", but at a workflow state of 
> "Closed" or "Resolved".  Unfortunately, the bulk change feature only 
> lets you change the workflow state, not the "Resolved" field value.   
> This is particularly a problem because the default issue filter keys on 
> the resolved field, not the workflow state.
> 
> Any volunteers to fix the issues one by one? :)
> 
> Don
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Ted Husted

SAF2 is based on the WebWork 2.2 codebase, which uses Interceptors
much the same way the SAF1.3 uses a Chain of Responsiblity. The huge
difference is that the "Interceptor Stack" or "Request Processor" can
be changed on an Action-by-Action basis. We haven't even started to
decide what the feature set for a SAF3 would look like. My other post
suggests that we stick to the original plan of having a "phase 1" and
"phase 2". Phase 2 might be SAF3 or it might be SAF2.1. The version
number is a decision we can make when the code is on the table.

-Ted.

On 4/24/06, netsql <[EMAIL PROTECTED]> wrote:
> Is SAF2 CoR based like 1.32 or is that SAF3?
>
> tia,
> .V
>
> >
> > The original proposal was for Ti to happen in two phases. The first
> > phase was to release Action 2.0 based on WebWork 2.2 by making only
> > necessary and prudent changes. More aggressive changes were to happen
> > in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
> > 2 might be Action 2.1 or Action 3.x. That's a decision we can make
> > later.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA cleanup

2006-04-24 Thread Ted Husted

Yes, it is something a non-committer can do.

-Ted

On 4/24/06, David Evans <[EMAIL PROTECTED]> wrote:
> Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
> willing to do this, if its something that a non commiter can do.
>
> dave
>
> On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:
> > Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to
> > be exact, that are resolved as "Unresolved", but at a workflow state of
> > "Closed" or "Resolved".  Unfortunately, the bulk change feature only
> > lets you change the workflow state, not the "Resolved" field value.
> > This is particularly a problem because the default issue filter keys on
> > the resolved field, not the workflow state.
> >
> > Any volunteers to fix the issues one by one? :)
> >
> > Don

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396556 - /incubator/webwork2/STATUS.txt

Author: husted
Date: Mon Apr 24 06:58:09 2006
New Revision: 396556

URL: http://svn.apache.org/viewcvs?rev=396556&view=rev
Log:
Add board status report for April

Modified:
incubator/webwork2/STATUS.txt

Modified: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=396556&r1=396555&r2=396556&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Apr 24 06:58:09 2006
@@ -23,6 +23,42 @@
 
 
 
+BOARD STATUS REPORTS 
+
+[18 Apr 2006] 
+
+The last quarter has seen the creation of the WebWork 2 podling and rapid 
progress.  Our focus has been on migrating
+code, resources, developers, IP, and community over to the ASF.
+
+ - Code: we have imported the code into the Incubator SVN, and have renamed 
packages, taglib prefixes, and any other
+references to the old WebWork project over to the new Struts Action Framework 
2 project, where the final location of the
+code will be.
+
+ - Resources: We've migrated the code to the Apache SVN, setup and migrated 
JIRA tickets to the new issues.apache.org
+server, and are in the process of migration wiki documentation.
+
+ - Developers: The core WebWork 2 developers have been given accounts and 
access to the podling, voted in through the
+proposal.  We plan to vote the remaining committers in one-by-one through the 
Struts PMC, serving as the IPMC for the
+podling.
+
+ - IP: The OpenSymphony organization, who owns the copyright on the WebWork 2 
project, has delivered a code grant
+allowing us to change the copyright.  Additionally, we've removed most of the 
LGPL source code (usually in the form of
+Javascript libraries) and have developed an optional build that compiles 
integration code depending on LGPL jars, in
+accordance to the draft IP policy document.
+
+ - Community: The WebWork 2 developers have joined the Struts mailing lists 
and have been very active in participating
+with both development and user threads.  They have been just as, if not more, 
active committing to the code repository
+as Struts committers, and when conflicts arise, they are very quick to come to 
a solution in a positive way.  In
+addition, several Struts committers have joined OpenSymphony forums, chat 
rooms, and projects further strengthening the
+relationship.
+
+We are definitely planning on exiting the Incubator this next quarter, 
possibly within weeks.  We see a bright future
+for the Struts Action project, and hope to facilitate a new spirit of 
cooperation within the competitive landscape of
+Java web application frameworks
+
+
+
+
 DISTRIBUTION RIGHTS - LICENSING
 
 optiontransferselect.js



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA cleanup

2006-04-24 Thread David Evans

Ok. I just signed up for an account at http://issues.apache.org, and did
a search on status "Closed" and resolutions "Unresolved". I see the 182
issues, in the issue details, i don't have the "available workflow
actions" section on the left. I signed up for a test account on
altassian's site, so i see what needs to be done, i believe (reopen,
change resolution, then close). There's also the  question of which
resolution i should set these items to. 

Dave  


On Mon, 2006-04-24 at 09:55 -0400, Ted Husted wrote:
> Yes, it is something a non-committer can do.
> 
> -Ted
> 
> On 4/24/06, David Evans <[EMAIL PROTECTED]> wrote:
> > Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
> > willing to do this, if its something that a non commiter can do.
> >
> > dave
> >
> > On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:
> > > Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to
> > > be exact, that are resolved as "Unresolved", but at a workflow state of
> > > "Closed" or "Resolved".  Unfortunately, the bulk change feature only
> > > lets you change the workflow state, not the "Resolved" field value.
> > > This is particularly a problem because the default issue filter keys on
> > > the resolved field, not the workflow state.
> > >
> > > Any volunteers to fix the issues one by one? :)
> > >
> > > Don
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396566 - /struts/site/src/site/fml/helping.fml

Author: husted
Date: Mon Apr 24 07:28:31 2006
New Revision: 396566

URL: http://svn.apache.org/viewcvs?rev=396566&view=rev
Log:
Helping FAQ 
* Update links to JIRA 

Modified:
struts/site/src/site/fml/helping.fml

Modified: struts/site/src/site/fml/helping.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/src/site/fml/helping.fml?rev=396566&r1=396565&r2=396566&view=diff
==
--- struts/site/src/site/fml/helping.fml (original)
+++ struts/site/src/site/fml/helping.fml Mon Apr 24 07:28:31 2006
@@ -102,7 +102,7 @@
 
 
 Just using the products is a very important role.
-We need people who will report bugs, contribute patches,
+We need people who will report issues, contribute patches,
 suggest
 features, and so forth.
 Your feedback helps the technology to evolve.
@@ -172,7 +172,7 @@
 one afternoon a week (or more if you can spare the
 resources).
 Have your team member browse
-Bugzilla
+JIRA
 for any issues
 without a
 patch
@@ -268,8 +268,8 @@
 
 
 Then, create a
-Bugzilla
-report
+JIRA
+issue
 about the change, and attach the patch file.
 
 
@@ -278,8 +278,8 @@
 the mailing
 list.
 We would prefer that you create a
-Bugzilla report and then attach the patch to the report.
-To do this, you must first create the report,
+JIRA issue and then attach the patch to the issue.
+To do this, you must first create the issue,
 and then modify the report to add your patch.
 We realize this is a bit clumsy, but it keeps us from
 losing things,
@@ -297,17 +297,16 @@
 
 
 
-
-How can I report bugs or suggest features?
+
+How can I report defects or suggest features?
 
 
-Tracking of bug reports and enhancement suggestions for
+Tracking of defect reports and enhancement suggestions for
 Apache Struts
-subprojects is handled
+products is handled
 through the
-http://issues.apache.org/bugzilla";>Apache Bug
-Database
-(Bugzilla).
+http://issues.apache.org/struts/";>Apache Struts 
+JIRA instance.
 Please select
 Struts
 from the product list, along with
@@ -315,7 +314,7 @@
 report
 relates to, and details of your operating environment.
 You will automatically be notified by email as the status
-of your bug or
+of your defect or
 enhancement report changes.
 Please be sure to read
 http://www.chiark.greenend.org.uk/~sgtatham/bugs.html";>
@@ -325,31 +324,16 @@
 
 
 
-You can research and report outstanding fixes and feature
-suggestions
-using Bugzilla.
-If you are unsure if this is an actual problem,
-feel free to bring it up on the list first.
-But to be sure that an issue is resolved, read
-http://www.chiark.greenend.org.uk/~sgtatham/bugs.html";>
-How to Report Bugs Effectively
-and report it to
-http://issues.apache.org/bugzilla";>
-Bugzilla.
-
-
-
-
 If you can't write a
 patch
-to fix your bug,
+to address your issue,
 a unit test that demonstrates the problem is also welcome.
 (And, of course, unit tests that prove your patch works
 are equally welcome.)
 
 
 
-If your bug or feature is already in Bugzilla,
+If the defect or feature is already being tracked,
 you can vote for the issue and call more attention to it.
 Each user can cast up to six votes at a time.
 
@@ -368,13 +352,12 @@

Re: JIRA cleanup

First, thanks for jumping in!  I added you to the struts-developers 
group, which should give you the appropriate access.  As for the 
changes, move "Unresolved" to "Fixed".


Don

David Evans wrote:

Ok. I just signed up for an account at http://issues.apache.org, and did
a search on status "Closed" and resolutions "Unresolved". I see the 182
issues, in the issue details, i don't have the "available workflow
actions" section on the left. I signed up for a test account on
altassian's site, so i see what needs to be done, i believe (reopen,
change resolution, then close). There's also the  question of which
resolution i should set these items to. 

Dave  



On Mon, 2006-04-24 at 09:55 -0400, Ted Husted wrote:

Yes, it is something a non-committer can do.

-Ted

On 4/24/06, David Evans <[EMAIL PROTECTED]> wrote:

Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
willing to do this, if its something that a non commiter can do.

dave

On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:

Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to
be exact, that are resolved as "Unresolved", but at a workflow state of
"Closed" or "Resolved".  Unfortunately, the bulk change feature only
lets you change the workflow state, not the "Resolved" field value.
This is particularly a problem because the default issue filter keys on
the resolved field, not the workflow state.

Any volunteers to fix the issues one by one? :)

Don

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standalone Tiles as TLP

2006-04-24 Thread Nathan Bubna

On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> > I would think it would be Tiles' responsibility to support deployment
> > with Struts.  In that view, Tiles would be its own project, yet part of
> > it would depend on struts-action.jar to provide the Struts hooks.  In
> > the same way, they would provide Struts Action 2 hooks, if necessary.
>
>
> This is a tough one - for me, at least. Should an independent Tiles have
> glue code for Struts, or should it be Struts' responsibility to provide the
> glue? If we look at Velocity, the glue is over there, but we've also talked
> about it coming here. If we look at Validator, the glue is here. If we look
> at Chain, the servlet and portlet glue is over there.
>
> My preference, at least at this time, would be for the Struts / Tiles glue
> to stay here. That will help Standalone Tiles stand on its own feet, and
> especially help with the notion that it's now independent of Struts. Any
> perception - real or otherwise - that Tiles is tied to Struts will be
> detrimental to Tiles as an independent library.

+1 Let's keep the Struts-Tiles code and Tiles-Velocity type code out
of stand-alone tiles for the moment.  I think a better time for moving
those over would be once Tiles is established and released as an
independent Jakarta Web Component.

> --
> Martin Cooper
>
>
> Don
> >
> > Wendy Smoak wrote:
> > > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > >
> > >> Agreed.  Would it be possible to do this by JavaOne?  Moving Tiles
> > isn't
> > >> a huge deal, but it would make the new directions of Struts easier to
> > >> explain to users.
> > >>
> > >
> > > What happens to Struts Tiles, then?  I'm not sure I understand why
> > > we're holding Struts Tiles out of the Struts Action distribution.
> > >
> > > Won't there always be a struts-tiles.jar of some kind, whether it's
> > > the current one with all the code, or a much lighter version that
> > > works with Standalone Tiles?
> > >
> > > --
> > > Wendy
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Confluence migration next step: Migrate content

Ok, the permissions should be fixed.  Let me know if you have any more 
issues,


Don

tm jee wrote:

Hey guys,
 
 I've registered myself with the confluence at http://confluence.twdata.org .
 
 Can't seems to see any WebWork related documents there. Is it possible that the data haven't been loaded to this instance yet? Or are we suppose to migrate it on a page by page basis?
 
 rgds


- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, 24 April, 2006 8:50:02 AM
Subject: [action2] Confluence migration next step: Migrate content

Patrick and I have implemented the first steps of the migration plan:
 - The OpenSymphony WebWork wiki is read-only, save for the project 
developers for rare changes
 - I installed a Confluence instance on my personal server: 
http://confluence.twdata.org

 - Patrick exported the data and loaded it into the new instance

Therefore, we now are at the stage where we need to rename the 
documentation.  The end goal is that we migrate the content to an ASF 
Confluence instance, but until one is available, please work on the 
twdata one so we can at least continue moving forward.


Any user account should be able to edit pages, but if you need admin 
access, let me know.


Again, the server is at http://confluence.twdata.org and everyone please 
join in the effort to migrate its content.  Feel free to add new 
information as well, as this data will be loaded into the ASF instance.


Don

http://confluence.twdata.org  <-- one more time :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[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]

[jira] Reopened: (STR-2774) ActionForm should not be populated automatically [Struts Classic 1.x]

 [ http://issues.apache.org/struts/browse/STR-2774?page=all ]
 
David Evans reopened STR-2774:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

during import from bugzilla ticket, had resolved field set to unresolved with 
status set to closed. reopening to set resolved field to resolved.

> ActionForm should not be populated automatically [Struts Classic 1.x]
> -
>
>  Key: STR-2774
>  URL: http://issues.apache.org/struts/browse/STR-2774
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Michael Jouravlev
> Assignee: David Evans
> Priority: Minor

>
> Whenever a request is submitted to an Action, a corresponding ActionForm is
> always populated, despite the type of request or despite of whether request
> contains Cancel event or not. This brings a lot of problems related to
> refreshing the same page, or forwarding to another action, or accepting 
> invalid
> input when Cancel was activated.
> For compatibility reasons, autopopulation of an ActionForm should be kept by
> default, but it should be possible to turn it off either on application level
> using  element or on action level using  element, or both.
> Struts allows to perform validation explicitly, the same should be allowed for
> form population. A developer knows better when to accept the input and when 
> not to.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2774) ActionForm should not be populated automatically [Struts Classic 1.x]

 [ http://issues.apache.org/struts/browse/STR-2774?page=all ]
 
David Evans resolved STR-2774:
--

Resolution: Fixed

during import from bugzilla ticket, had resolved field set to unresolved with 
status set to closed. setting resolved field to fixed.

> ActionForm should not be populated automatically [Struts Classic 1.x]
> -
>
>  Key: STR-2774
>  URL: http://issues.apache.org/struts/browse/STR-2774
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Michael Jouravlev
> Assignee: David Evans
> Priority: Minor

>
> Whenever a request is submitted to an Action, a corresponding ActionForm is
> always populated, despite the type of request or despite of whether request
> contains Cancel event or not. This brings a lot of problems related to
> refreshing the same page, or forwarding to another action, or accepting 
> invalid
> input when Cancel was activated.
> For compatibility reasons, autopopulation of an ActionForm should be kept by
> default, but it should be possible to turn it off either on application level
> using  element or on action level using  element, or both.
> Struts allows to perform validation explicitly, the same should be allowed for
> form population. A developer knows better when to accept the input and when 
> not to.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2774) ActionForm should not be populated automatically [Struts Classic 1.x]

 [ http://issues.apache.org/struts/browse/STR-2774?page=all ]
 
David Evans closed STR-2774:



> ActionForm should not be populated automatically [Struts Classic 1.x]
> -
>
>  Key: STR-2774
>  URL: http://issues.apache.org/struts/browse/STR-2774
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Michael Jouravlev
> Assignee: David Evans
> Priority: Minor

>
> Whenever a request is submitted to an Action, a corresponding ActionForm is
> always populated, despite the type of request or despite of whether request
> contains Cancel event or not. This brings a lot of problems related to
> refreshing the same page, or forwarding to another action, or accepting 
> invalid
> input when Cancel was activated.
> For compatibility reasons, autopopulation of an ActionForm should be kept by
> default, but it should be possible to turn it off either on application level
> using  element or on action level using  element, or both.
> Struts allows to perform validation explicitly, the same should be allowed for
> form population. A developer knows better when to accept the input and when 
> not to.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2749) html form tags generate invalid XHTML

 [ http://issues.apache.org/struts/browse/STR-2749?page=all ]
 
David Evans reopened STR-2749:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> html form tags generate invalid XHTML
> -
>
>  Key: STR-2749
>  URL: http://issues.apache.org/struts/browse/STR-2749
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Bruce Link
> Assignee: David Evans

>
> : there is no attribute "name",
> , , ,  />,
> , : generates  start tag, not empty tag 
> (no />)
> Generates W3C validation error message: "end tag for "input" omitted, but
> OMITTAG NO was specified."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2749) html form tags generate invalid XHTML

 [ http://issues.apache.org/struts/browse/STR-2749?page=all ]
 
David Evans resolved STR-2749:
--

Resolution: Fixed

during import from bugzilla ticket, had resolved field set to unresolved with 
status set to closed. setting resolved field to fixed.

> html form tags generate invalid XHTML
> -
>
>  Key: STR-2749
>  URL: http://issues.apache.org/struts/browse/STR-2749
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Bruce Link
> Assignee: David Evans

>
> : there is no attribute "name",
> , , ,  />,
> , : generates  start tag, not empty tag 
> (no />)
> Generates W3C validation error message: "end tag for "input" omitted, but
> OMITTAG NO was specified."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA cleanup

2006-04-24 Thread David Evans

No problem, glad to help. I've started, i did two tickets and was adding
comments:
http://issues.apache.org/struts/browse/STR-2749

Looking at the way these are displayed, it seems my comment isn't really
needed. Any preference one way or the other?

Dave


On Mon, 2006-04-24 at 07:56 -0700, Don Brown wrote:
> First, thanks for jumping in!  I added you to the struts-developers 
> group, which should give you the appropriate access.  As for the 
> changes, move "Unresolved" to "Fixed".
> 
> Don
> 
> David Evans wrote:
> > Ok. I just signed up for an account at http://issues.apache.org, and did
> > a search on status "Closed" and resolutions "Unresolved". I see the 182
> > issues, in the issue details, i don't have the "available workflow
> > actions" section on the left. I signed up for a test account on
> > altassian's site, so i see what needs to be done, i believe (reopen,
> > change resolution, then close). There's also the  question of which
> > resolution i should set these items to. 
> > 
> > Dave  
> > 
> > 
> > On Mon, 2006-04-24 at 09:55 -0400, Ted Husted wrote:
> >> Yes, it is something a non-committer can do.
> >>
> >> -Ted
> >>
> >> On 4/24/06, David Evans <[EMAIL PROTECTED]> wrote:
> >>> Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
> >>> willing to do this, if its something that a non commiter can do.
> >>>
> >>> dave
> >>>
> >>> On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:
>  Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to
>  be exact, that are resolved as "Unresolved", but at a workflow state of
>  "Closed" or "Resolved".  Unfortunately, the bulk change feature only
>  lets you change the workflow state, not the "Resolved" field value.
>  This is particularly a problem because the default issue filter keys on
>  the resolved field, not the workflow state.
> 
>  Any volunteers to fix the issues one by one? :)
> 
>  Don
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA cleanup


I wouldn't worry about, but it is up to you.

Don

David Evans wrote:

No problem, glad to help. I've started, i did two tickets and was adding
comments:
http://issues.apache.org/struts/browse/STR-2749

Looking at the way these are displayed, it seems my comment isn't really
needed. Any preference one way or the other?

Dave


On Mon, 2006-04-24 at 07:56 -0700, Don Brown wrote:
First, thanks for jumping in!  I added you to the struts-developers 
group, which should give you the appropriate access.  As for the 
changes, move "Unresolved" to "Fixed".


Don

David Evans wrote:

Ok. I just signed up for an account at http://issues.apache.org, and did
a search on status "Closed" and resolutions "Unresolved". I see the 182
issues, in the issue details, i don't have the "available workflow
actions" section on the left. I signed up for a test account on
altassian's site, so i see what needs to be done, i believe (reopen,
change resolution, then close). There's also the  question of which
resolution i should set these items to. 

Dave  



On Mon, 2006-04-24 at 09:55 -0400, Ted Husted wrote:

Yes, it is something a non-committer can do.

-Ted

On 4/24/06, David Evans <[EMAIL PROTECTED]> wrote:

Hello, my name is Dave Evans, I've been lurking here for a while. I'd be
willing to do this, if its something that a non commiter can do.

dave

On Sun, 2006-04-23 at 23:43 -0700, Don Brown wrote:

Thanks to our Bugzilla import, we seem to have a bunch of issues, 182 to
be exact, that are resolved as "Unresolved", but at a workflow state of
"Closed" or "Resolved".  Unfortunately, the bulk change feature only
lets you change the workflow state, not the "Resolved" field value.
This is particularly a problem because the default issue filter keys on
the resolved field, not the workflow state.

Any volunteers to fix the issues one by one? :)

Don

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standalone Tiles as TLP

2006-04-24 Thread Joe Germuska


+1 Let's keep the Struts-Tiles code and Tiles-Velocity type code out
of stand-alone tiles for the moment.  I think a better time for moving
those over would be once Tiles is established and released as an
independent Jakarta Web Component.


Personally, I doubt there would ever be a "right time" to put glue 
code like that in Tiles.  It strikes me that the glue is more about 
the non-tiles side of thing (at least from what I recall when I wrote 
the struts-chain code to handle tiles forward destinations.)


I'd argue that any code to make Struts work well with Tiles belongs 
in Struts projects (and the same for tiles-velocity probably, 
although I don't really know that code.)


Joe

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2740) Add support for XHTML 1.1 and XHTML 2.0 etc.

 [ http://issues.apache.org/struts/browse/STR-2740?page=all ]
 
David Evans reopened STR-2740:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Add support for XHTML 1.1 and XHTML 2.0 etc.
> 
>
>  Key: STR-2740
>  URL: http://issues.apache.org/struts/browse/STR-2740
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: All
> Platform: All
> Reporter: Bruce Link
> Assignee: David Evans
> Priority: Minor
>  Attachments: HTMLTag.java.patch
>
> Using  or  
> results
> in http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US">
> being generated.  The attribute lang="en-US" is not legal with XHTML 1.1.  The
> tag is ignoring the fact that lang="false" This is because in the if statement
> that checks for this.lang || this.local the condition this.xhtml has been 
> added.
> The bug is also in the latest version of HTMLTag.java in the repository.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2740) Add support for XHTML 1.1 and XHTML 2.0 etc.

 [ http://issues.apache.org/struts/browse/STR-2740?page=all ]
 
David Evans resolved STR-2740:
--

Resolution: Fixed

> Add support for XHTML 1.1 and XHTML 2.0 etc.
> 
>
>  Key: STR-2740
>  URL: http://issues.apache.org/struts/browse/STR-2740
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: All
> Platform: All
> Reporter: Bruce Link
> Assignee: David Evans
> Priority: Minor
>  Attachments: HTMLTag.java.patch
>
> Using  or  
> results
> in http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US">
> being generated.  The attribute lang="en-US" is not legal with XHTML 1.1.  The
> tag is ignoring the fact that lang="false" This is because in the if statement
> that checks for this.lang || this.local the condition this.xhtml has been 
> added.
> The bug is also in the latest version of HTMLTag.java in the repository.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2740) Add support for XHTML 1.1 and XHTML 2.0 etc.

 [ http://issues.apache.org/struts/browse/STR-2740?page=all ]
 
David Evans closed STR-2740:



> Add support for XHTML 1.1 and XHTML 2.0 etc.
> 
>
>  Key: STR-2740
>  URL: http://issues.apache.org/struts/browse/STR-2740
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: All
> Platform: All
> Reporter: Bruce Link
> Assignee: David Evans
> Priority: Minor
>  Attachments: HTMLTag.java.patch
>
> Using  or  
> results
> in http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US">
> being generated.  The attribute lang="en-US" is not legal with XHTML 1.1.  The
> tag is ignoring the fact that lang="false" This is because in the if statement
> that checks for this.lang || this.local the condition this.xhtml has been 
> added.
> The bug is also in the latest version of HTMLTag.java in the repository.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396587 - /struts/action/trunk/src/site/site.xml

Author: wsmoak
Date: Mon Apr 24 08:49:57 2006
New Revision: 396587

URL: http://svn.apache.org/viewcvs?rev=396587&view=rev
Log:
Add Struts Tiles to the menu.

Modified:
struts/action/trunk/src/site/site.xml

Modified: struts/action/trunk/src/site/site.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/src/site/site.xml?rev=396587&r1=396586&r2=396587&view=diff
==
--- struts/action/trunk/src/site/site.xml (original)
+++ struts/action/trunk/src/site/site.xml Mon Apr 24 08:49:57 2006
@@ -88,6 +88,9 @@
 
 
+
+
 
 
 ${modules}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2739) [extras] ParameterListActionDispatcher

 [ http://issues.apache.org/struts/browse/STR-2739?page=all ]
 
David Evans reopened STR-2739:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> [extras] ParameterListActionDispatcher
> --
>
>  Key: STR-2739
>  URL: http://issues.apache.org/struts/browse/STR-2739
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.3.0
>  Environment: Operating System: other
> Platform: Other
> Reporter: Paul Benedict
> Assignee: David Evans
> Priority: Minor
>  Attachments: ParameterListActionDispatcher.java, 
> ParameterListActionDispatcher.java, ParameterListActionDispatcher.java, 
> ParameterMappingDispatchAction.java, ParameterMappingDispatchAction.java
>
> The attached ParameterMappingDispatchAction class is a proposed enhancement to
> MappingDispatchAction either as a subclass or a direct replacement. Here are 
> the
> added benefits:
> 1) For a form with multiple buttons, the parameter attribute can contain a 
> list
> of appropriate methods to iterate for a match. These methods are matched 
> against
> incoming request parameters (as well as button .x/.y suffixes). For security
> reasons, a developer may want to limit which methods to invoke for a 
> particular
> mapping, unlike DispatchAction which will match any existing method.
> 
> 2) ParameterMappingDispatchAction provided the ability to also obfuscate 
> method
> names, and so does this by providing a key=value mapping. The key will be the
> request parameter name and the value the method name. 
> 
> 3) Sometimes the user presses Enter to submit the form and no button is
> explicitly submitted. When this case is important to catch, the action may
> invoke the "default" method if nothing matches. In this example, the default 
> is
> to save.
> 
> 4) When only one method is listed, the method returns it to equal 
> functionality
> to MappingDispatchAction.
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2739) [extras] ParameterListActionDispatcher

 [ http://issues.apache.org/struts/browse/STR-2739?page=all ]
 
David Evans closed STR-2739:



> [extras] ParameterListActionDispatcher
> --
>
>  Key: STR-2739
>  URL: http://issues.apache.org/struts/browse/STR-2739
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.3.0
>  Environment: Operating System: other
> Platform: Other
> Reporter: Paul Benedict
> Assignee: David Evans
> Priority: Minor
>  Attachments: ParameterListActionDispatcher.java, 
> ParameterListActionDispatcher.java, ParameterListActionDispatcher.java, 
> ParameterMappingDispatchAction.java, ParameterMappingDispatchAction.java
>
> The attached ParameterMappingDispatchAction class is a proposed enhancement to
> MappingDispatchAction either as a subclass or a direct replacement. Here are 
> the
> added benefits:
> 1) For a form with multiple buttons, the parameter attribute can contain a 
> list
> of appropriate methods to iterate for a match. These methods are matched 
> against
> incoming request parameters (as well as button .x/.y suffixes). For security
> reasons, a developer may want to limit which methods to invoke for a 
> particular
> mapping, unlike DispatchAction which will match any existing method.
> 
> 2) ParameterMappingDispatchAction provided the ability to also obfuscate 
> method
> names, and so does this by providing a key=value mapping. The key will be the
> request parameter name and the value the method name. 
> 
> 3) Sometimes the user presses Enter to submit the form and no button is
> explicitly submitted. When this case is important to catch, the action may
> invoke the "default" method if nothing matches. In this example, the default 
> is
> to save.
> 
> 4) When only one method is listed, the method returns it to equal 
> functionality
> to MappingDispatchAction.
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2739) [extras] ParameterListActionDispatcher

 [ http://issues.apache.org/struts/browse/STR-2739?page=all ]
 
David Evans resolved STR-2739:
--

Resolution: Fixed

> [extras] ParameterListActionDispatcher
> --
>
>  Key: STR-2739
>  URL: http://issues.apache.org/struts/browse/STR-2739
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.3.0
>  Environment: Operating System: other
> Platform: Other
> Reporter: Paul Benedict
> Assignee: David Evans
> Priority: Minor
>  Attachments: ParameterListActionDispatcher.java, 
> ParameterListActionDispatcher.java, ParameterListActionDispatcher.java, 
> ParameterMappingDispatchAction.java, ParameterMappingDispatchAction.java
>
> The attached ParameterMappingDispatchAction class is a proposed enhancement to
> MappingDispatchAction either as a subclass or a direct replacement. Here are 
> the
> added benefits:
> 1) For a form with multiple buttons, the parameter attribute can contain a 
> list
> of appropriate methods to iterate for a match. These methods are matched 
> against
> incoming request parameters (as well as button .x/.y suffixes). For security
> reasons, a developer may want to limit which methods to invoke for a 
> particular
> mapping, unlike DispatchAction which will match any existing method.
> 
> 2) ParameterMappingDispatchAction provided the ability to also obfuscate 
> method
> names, and so does this by providing a key=value mapping. The key will be the
> request parameter name and the value the method name. 
> 
> 3) Sometimes the user presses Enter to submit the form and no button is
> explicitly submitted. When this case is important to catch, the action may
> invoke the "default" method if nothing matches. In this example, the default 
> is
> to save.
> 
> 4) When only one method is listed, the method returns it to equal 
> functionality
> to MappingDispatchAction.
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2712) Warnings on generating validator's static javascript

 [ http://issues.apache.org/struts/browse/STR-2712?page=all ]
 
David Evans reopened STR-2712:
--

Assign To: (was: Struts Developer Mailing List)

> Warnings on generating validator's static javascript
> 
>
>  Key: STR-2712
>  URL: http://issues.apache.org/struts/browse/STR-2712
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dmitrii CRETU

>
> Configuration
> =
> * struts-1.2.8
> * commons-validator-1.2.0 (NOT 1.1.4 coming by default with struts-1.2.8)
> 
> * put static (common) JavaScript into a single jsp :
> 
> 
> 
> 
> 
> Issue
> =
> After migrating to configuration described above we permanently get the 
> following log message while running our applications :
> 
> Dec 30, 2005 12:15:56 PM org.apache.commons.validator.ValidatorResources 
> getForm
> WARNING: Form 'null' not found for locale 'en_US'
> 
> Cause
> =
> * JavascriptValidatorTag.renderJavascript() calls 
>   ValidatorResources.getForm(...) even when dynamicJavascript=false
> * Since 1.2.0 ValidatorResources.getForm(...) method posts this warning 
> if 
>   no form is found for given formKey, null in our case
> Solution proposed
> =
> Not to call getForm() when dynamicJavascript=false (we don't need form's
> validation rules in this case - as far as I can see).
> In class org.apache.struts.taglib.html.JavascriptValidatorTag ($Rev: 331265 
> $) 
> from line 380 :
> 
> 380,388c380,391
> < Form form = resources.getForm(locale, formName);
> <
> < if ("true".equalsIgnoreCase(dynamicJavascript) && form == null)
> < {
> < throw new JspException("No form found under '"
> <+ formName
> <+ "' in locale '"
> <+ locale
> <+ "'");
> ---
> > Form form = null;
> >
> > // we only need form's resources when generating dynamic javascript
> > if ("true".equalsIgnoreCase(dynamicJavascript)) {
> > form = resources.getForm(locale, formName);
> > if (form == null) {
> > throw new JspException("No form found under '"
> >+ formName
> >+ "' in locale '"
> >+ locale
> >+ "'");
> > }
> 389a393
> >
> 
> Note
> 
> Maybe it's a good idea to put in JavascriptValidatorTag a validation like 
> this :
> (dynamicJavascript==false && formName==null) 
>  || (dynamicJavascript==true && formName!=null)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2712) Warnings on generating validator's static javascript

 [ http://issues.apache.org/struts/browse/STR-2712?page=all ]
 
David Evans resolved STR-2712:
--

Resolution: Fixed

> Warnings on generating validator's static javascript
> 
>
>  Key: STR-2712
>  URL: http://issues.apache.org/struts/browse/STR-2712
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dmitrii CRETU

>
> Configuration
> =
> * struts-1.2.8
> * commons-validator-1.2.0 (NOT 1.1.4 coming by default with struts-1.2.8)
> 
> * put static (common) JavaScript into a single jsp :
> 
> 
> 
> 
> 
> Issue
> =
> After migrating to configuration described above we permanently get the 
> following log message while running our applications :
> 
> Dec 30, 2005 12:15:56 PM org.apache.commons.validator.ValidatorResources 
> getForm
> WARNING: Form 'null' not found for locale 'en_US'
> 
> Cause
> =
> * JavascriptValidatorTag.renderJavascript() calls 
>   ValidatorResources.getForm(...) even when dynamicJavascript=false
> * Since 1.2.0 ValidatorResources.getForm(...) method posts this warning 
> if 
>   no form is found for given formKey, null in our case
> Solution proposed
> =
> Not to call getForm() when dynamicJavascript=false (we don't need form's
> validation rules in this case - as far as I can see).
> In class org.apache.struts.taglib.html.JavascriptValidatorTag ($Rev: 331265 
> $) 
> from line 380 :
> 
> 380,388c380,391
> < Form form = resources.getForm(locale, formName);
> <
> < if ("true".equalsIgnoreCase(dynamicJavascript) && form == null)
> < {
> < throw new JspException("No form found under '"
> <+ formName
> <+ "' in locale '"
> <+ locale
> <+ "'");
> ---
> > Form form = null;
> >
> > // we only need form's resources when generating dynamic javascript
> > if ("true".equalsIgnoreCase(dynamicJavascript)) {
> > form = resources.getForm(locale, formName);
> > if (form == null) {
> > throw new JspException("No form found under '"
> >+ formName
> >+ "' in locale '"
> >+ locale
> >+ "'");
> > }
> 389a393
> >
> 
> Note
> 
> Maybe it's a good idea to put in JavascriptValidatorTag a validation like 
> this :
> (dynamicJavascript==false && formName==null) 
>  || (dynamicJavascript==true && formName!=null)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2712) Warnings on generating validator's static javascript

 [ http://issues.apache.org/struts/browse/STR-2712?page=all ]
 
David Evans closed STR-2712:



> Warnings on generating validator's static javascript
> 
>
>  Key: STR-2712
>  URL: http://issues.apache.org/struts/browse/STR-2712
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dmitrii CRETU

>
> Configuration
> =
> * struts-1.2.8
> * commons-validator-1.2.0 (NOT 1.1.4 coming by default with struts-1.2.8)
> 
> * put static (common) JavaScript into a single jsp :
> 
> 
> 
> 
> 
> Issue
> =
> After migrating to configuration described above we permanently get the 
> following log message while running our applications :
> 
> Dec 30, 2005 12:15:56 PM org.apache.commons.validator.ValidatorResources 
> getForm
> WARNING: Form 'null' not found for locale 'en_US'
> 
> Cause
> =
> * JavascriptValidatorTag.renderJavascript() calls 
>   ValidatorResources.getForm(...) even when dynamicJavascript=false
> * Since 1.2.0 ValidatorResources.getForm(...) method posts this warning 
> if 
>   no form is found for given formKey, null in our case
> Solution proposed
> =
> Not to call getForm() when dynamicJavascript=false (we don't need form's
> validation rules in this case - as far as I can see).
> In class org.apache.struts.taglib.html.JavascriptValidatorTag ($Rev: 331265 
> $) 
> from line 380 :
> 
> 380,388c380,391
> < Form form = resources.getForm(locale, formName);
> <
> < if ("true".equalsIgnoreCase(dynamicJavascript) && form == null)
> < {
> < throw new JspException("No form found under '"
> <+ formName
> <+ "' in locale '"
> <+ locale
> <+ "'");
> ---
> > Form form = null;
> >
> > // we only need form's resources when generating dynamic javascript
> > if ("true".equalsIgnoreCase(dynamicJavascript)) {
> > form = resources.getForm(locale, formName);
> > if (form == null) {
> > throw new JspException("No form found under '"
> >+ formName
> >+ "' in locale '"
> >+ locale
> >+ "'");
> > }
> 389a393
> >
> 
> Note
> 
> Maybe it's a good idea to put in JavascriptValidatorTag a validation like 
> this :
> (dynamicJavascript==false && formName==null) 
>  || (dynamicJavascript==true && formName!=null)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2682) TagUtils doesn't create XHTML compliant URLs when called from LinkTag when using forwards defined with redirect="true"

 [ http://issues.apache.org/struts/browse/STR-2682?page=all ]
 
David Evans reopened STR-2682:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> TagUtils doesn't create XHTML compliant URLs when called from LinkTag when 
> using forwards defined with redirect="true"
> --
>
>  Key: STR-2682
>  URL: http://issues.apache.org/struts/browse/STR-2682
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jason A. Lunn
> Assignee: David Evans
>  Attachments: link_xhtml_compliance.patch, struts_tagutils_redirect.patch
>
> html:link tags using the "forward" attribute to reference an ActionForward 
> where the redirect attribute is 
> true do not render XHTML compliant URLs in all cases. The problem manifests 
> when using a Map to 
> include multiple parameters because the ampersand in the URL is not properly 
> escaped. This is because 
> the separator variable in TagUtils.computeURLWithCharEncoding() is defined 
> after the value of the function 
> argument "redirect" is overridden by the value of of 
> forwardConfig.getRedirect()
> By simply moving the small block of code that determines the value of 
> "separator" to be before the block 
> of code that inspects the state of forwardConfig, XHTML compliant URLs can be 
> rendered by the html:link 
> tag without negatively impacting the logic:redirect tags need to force 
> unescaped ampersands.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2682) TagUtils doesn't create XHTML compliant URLs when called from LinkTag when using forwards defined with redirect="true"

 [ http://issues.apache.org/struts/browse/STR-2682?page=all ]
 
David Evans resolved STR-2682:
--

Resolution: Fixed

> TagUtils doesn't create XHTML compliant URLs when called from LinkTag when 
> using forwards defined with redirect="true"
> --
>
>  Key: STR-2682
>  URL: http://issues.apache.org/struts/browse/STR-2682
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jason A. Lunn
> Assignee: David Evans
>  Attachments: link_xhtml_compliance.patch, struts_tagutils_redirect.patch
>
> html:link tags using the "forward" attribute to reference an ActionForward 
> where the redirect attribute is 
> true do not render XHTML compliant URLs in all cases. The problem manifests 
> when using a Map to 
> include multiple parameters because the ampersand in the URL is not properly 
> escaped. This is because 
> the separator variable in TagUtils.computeURLWithCharEncoding() is defined 
> after the value of the function 
> argument "redirect" is overridden by the value of of 
> forwardConfig.getRedirect()
> By simply moving the small block of code that determines the value of 
> "separator" to be before the block 
> of code that inspects the state of forwardConfig, XHTML compliant URLs can be 
> rendered by the html:link 
> tag without negatively impacting the logic:redirect tags need to force 
> unescaped ampersands.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2682) TagUtils doesn't create XHTML compliant URLs when called from LinkTag when using forwards defined with redirect="true"

 [ http://issues.apache.org/struts/browse/STR-2682?page=all ]
 
David Evans closed STR-2682:



> TagUtils doesn't create XHTML compliant URLs when called from LinkTag when 
> using forwards defined with redirect="true"
> --
>
>  Key: STR-2682
>  URL: http://issues.apache.org/struts/browse/STR-2682
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.8
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jason A. Lunn
> Assignee: David Evans
>  Attachments: link_xhtml_compliance.patch, struts_tagutils_redirect.patch
>
> html:link tags using the "forward" attribute to reference an ActionForward 
> where the redirect attribute is 
> true do not render XHTML compliant URLs in all cases. The problem manifests 
> when using a Map to 
> include multiple parameters because the ampersand in the URL is not properly 
> escaped. This is because 
> the separator variable in TagUtils.computeURLWithCharEncoding() is defined 
> after the value of the function 
> argument "redirect" is overridden by the value of of 
> forwardConfig.getRedirect()
> By simply moving the small block of code that determines the value of 
> "separator" to be before the block 
> of code that inspects the state of forwardConfig, XHTML compliant URLs can be 
> rendered by the html:link 
> tag without negatively impacting the logic:redirect tags need to force 
> unescaped ampersands.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standalone Tiles as TLP

2006-04-24 Thread Greg Reddin


My time is very limited today so I'll respond quickly.

1)  I want to get Tiles as close to a release as possible by J1, but  
it's a daunting task.  The only huge effort is factoring out  
dependencies on the Servlet API, then testing.


2)  I'm cool with joint up with the Jakarta Web Components, even  
though I don't have very much experience with it.  If it provides  
more people who are interested in continuing Tiles, it can't be a bad  
thing.


3)  I prefer the approach of other frameworks providing their own  
hooks into Tiles as opposed to the other way round.  If Tiles  
provides the hooks, then it has to depend on all those frameworks.


I'll try really hard to find some time this week to put into the  
final refactoring efforts.


Thanks,
Greg

On Apr 23, 2006, at 5:35 PM, Craig McClanahan wrote:


On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote:


On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:


I would think it would be Tiles' responsibility to support  
deployment
with Struts.  In that view, Tiles would be its own project, yet  
part of
it would depend on struts-action.jar to provide the Struts  
hooks.  In
the same way, they would provide Struts Action 2 hooks, if  
necessary.



This is a tough one - for me, at least. Should an independent  
Tiles have
glue code for Struts, or should it be Struts' responsibility to  
provide

the
glue? If we look at Velocity, the glue is over there, but we've also
talked
about it coming here. If we look at Validator, the glue is here.  
If we

look
at Chain, the servlet and portlet glue is over there.



I've always thought it would be as Martin describes for Validator --
standalone Tiles would really be standalone, and each framework  
that wanted
to utilize it would provide it's own glue to some particular version 
(s) of
Standalone Tiles.  That is what Shale already does with the  
standalone Tiles

stuff -- for example, Shale integrates tiles into the standard JSF
navigation mechanism.  That's not something that it seems  
reasonable to

impose on a "standalone" project.

My preference, at least at this time, would be for the Struts /  
Tiles glue
to stay here. That will help Standalone Tiles stand on its own  
feet, and
especially help with the notion that it's now independent of  
Struts. Any

perception - real or otherwise - that Tiles is tied to Struts will be
detrimental to Tiles as an independent library.



+1

--

Martin Cooper



Craig



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2612) reset() support for DynaActionForm

 [ http://issues.apache.org/struts/browse/STR-2612?page=all ]
 
David Evans reopened STR-2612:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> reset() support for DynaActionForm
> --
>
>  Key: STR-2612
>  URL: http://issues.apache.org/struts/browse/STR-2612
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Hubert Rabago
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3.0
>  Attachments: dafr.txt
>
> Handling reset() for certain fields in dyna forms would help with the 
> requirements of the  tag.
> There are two approaches I've thought of so far.
> 1) Simply reset any boolean fields to false inside reset().  This could cause 
> backward-compatibility issues if anyone out there is using boolean fields in 
> action forms for anything other than checkboxes.
> 2) Allow the user to configure both an initial value and a reset flag.  This 
> could be something like:
>  name="MyForm" 
> type="org.apache.struts.action.DynaActionForm">
>  name="firstName" 
> type="java.lang.String" />
>  name="lastName" 
> type="java.lang.String" />
>  name="someFlag" 
> type="java.lang.String" 
> initial="false"
> reset="true"/>
> 
> Inside reset(), any property whose "reset" flag is set would be reset to its 
> initial value.
> This would require both a DTD change, and a way for the DynaActionForm to 
> know 
> what form name it is configured for.  For this, FormBeanConfig's 
> createActionForm() can be modified to pass along the name onto the 
> DynaActionForm it creates.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2612) reset() support for DynaActionForm

 [ http://issues.apache.org/struts/browse/STR-2612?page=all ]
 
David Evans resolved STR-2612:
--

Resolution: Fixed

> reset() support for DynaActionForm
> --
>
>  Key: STR-2612
>  URL: http://issues.apache.org/struts/browse/STR-2612
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Hubert Rabago
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3.0
>  Attachments: dafr.txt
>
> Handling reset() for certain fields in dyna forms would help with the 
> requirements of the  tag.
> There are two approaches I've thought of so far.
> 1) Simply reset any boolean fields to false inside reset().  This could cause 
> backward-compatibility issues if anyone out there is using boolean fields in 
> action forms for anything other than checkboxes.
> 2) Allow the user to configure both an initial value and a reset flag.  This 
> could be something like:
>  name="MyForm" 
> type="org.apache.struts.action.DynaActionForm">
>  name="firstName" 
> type="java.lang.String" />
>  name="lastName" 
> type="java.lang.String" />
>  name="someFlag" 
> type="java.lang.String" 
> initial="false"
> reset="true"/>
> 
> Inside reset(), any property whose "reset" flag is set would be reset to its 
> initial value.
> This would require both a DTD change, and a way for the DynaActionForm to 
> know 
> what form name it is configured for.  For this, FormBeanConfig's 
> createActionForm() can be modified to pass along the name onto the 
> DynaActionForm it creates.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2474) [shale] Serious issue with dialog state

 [ http://issues.apache.org/struts/browse/STR-2474?page=all ]
 
David Evans reopened STR-2474:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> [shale] Serious issue with dialog state
> ---
>
>  Key: STR-2474
>  URL: http://issues.apache.org/struts/browse/STR-2474
>  Project: Struts Action 1
> Type: Bug

>   Components: Shale
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: PC
> Reporter: sean schofield
> Assignee: David Evans

>
> Consider the following example:
> Start up the usecases example and begin creating a new profile.  Stop when you
> get to page 2.  Now open a new tab (use Firefox) and click the logon dialog
> again.  You get an exception:
> java.lang.IllegalArgumentException: Position[dialogName=Edit
> Profile,stateName=Page 2],outcome=dialog:Log On
> This is because you have initiated the same dialog without finishing the
> previous dialog.  This is not as crazy of a test as it might seem.  Consider
> what would happen if you opened the dialog in popup window (instead of a 
> browser
> tab) and the user closed the window prematurely ... same problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2612) reset() support for DynaActionForm

 [ http://issues.apache.org/struts/browse/STR-2612?page=all ]
 
David Evans closed STR-2612:



> reset() support for DynaActionForm
> --
>
>  Key: STR-2612
>  URL: http://issues.apache.org/struts/browse/STR-2612
>  Project: Struts Action 1
> Type: Improvement

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Hubert Rabago
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3.0
>  Attachments: dafr.txt
>
> Handling reset() for certain fields in dyna forms would help with the 
> requirements of the  tag.
> There are two approaches I've thought of so far.
> 1) Simply reset any boolean fields to false inside reset().  This could cause 
> backward-compatibility issues if anyone out there is using boolean fields in 
> action forms for anything other than checkboxes.
> 2) Allow the user to configure both an initial value and a reset flag.  This 
> could be something like:
>  name="MyForm" 
> type="org.apache.struts.action.DynaActionForm">
>  name="firstName" 
> type="java.lang.String" />
>  name="lastName" 
> type="java.lang.String" />
>  name="someFlag" 
> type="java.lang.String" 
> initial="false"
> reset="true"/>
> 
> Inside reset(), any property whose "reset" flag is set would be reset to its 
> initial value.
> This would require both a DTD change, and a way for the DynaActionForm to 
> know 
> what form name it is configured for.  For this, FormBeanConfig's 
> createActionForm() can be modified to pass along the name onto the 
> DynaActionForm it creates.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2474) [shale] Serious issue with dialog state

 [ http://issues.apache.org/struts/browse/STR-2474?page=all ]
 
David Evans resolved STR-2474:
--

Resolution: Fixed

> [shale] Serious issue with dialog state
> ---
>
>  Key: STR-2474
>  URL: http://issues.apache.org/struts/browse/STR-2474
>  Project: Struts Action 1
> Type: Bug

>   Components: Shale
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: PC
> Reporter: sean schofield
> Assignee: David Evans

>
> Consider the following example:
> Start up the usecases example and begin creating a new profile.  Stop when you
> get to page 2.  Now open a new tab (use Firefox) and click the logon dialog
> again.  You get an exception:
> java.lang.IllegalArgumentException: Position[dialogName=Edit
> Profile,stateName=Page 2],outcome=dialog:Log On
> This is because you have initiated the same dialog without finishing the
> previous dialog.  This is not as crazy of a test as it might seem.  Consider
> what would happen if you opened the dialog in popup window (instead of a 
> browser
> tab) and the user closed the window prematurely ... same problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2474) [shale] Serious issue with dialog state

 [ http://issues.apache.org/struts/browse/STR-2474?page=all ]
 
David Evans closed STR-2474:



> [shale] Serious issue with dialog state
> ---
>
>  Key: STR-2474
>  URL: http://issues.apache.org/struts/browse/STR-2474
>  Project: Struts Action 1
> Type: Bug

>   Components: Shale
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: PC
> Reporter: sean schofield
> Assignee: David Evans

>
> Consider the following example:
> Start up the usecases example and begin creating a new profile.  Stop when you
> get to page 2.  Now open a new tab (use Firefox) and click the logon dialog
> again.  You get an exception:
> java.lang.IllegalArgumentException: Position[dialogName=Edit
> Profile,stateName=Page 2],outcome=dialog:Log On
> This is because you have initiated the same dialog without finishing the
> previous dialog.  This is not as crazy of a test as it might seem.  Consider
> what would happen if you opened the dialog in popup window (instead of a 
> browser
> tab) and the user closed the window prematurely ... same problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r396591 - /struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml

Author: wsmoak
Date: Mon Apr 24 08:59:43 2006
New Revision: 396591

URL: http://svn.apache.org/viewcvs?rev=396591&view=rev
Log:
Tiles is not configured in the struts-blank app.

Modified:
struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml

Modified: 
struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml?rev=396591&r1=396590&r2=396591&view=diff
==
--- struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml 
(original)
+++ struts/action/trunk/apps/blank/src/main/webapp/WEB-INF/struts-config.xml 
Mon Apr 24 08:59:43 2006
@@ -8,8 +8,8 @@
  This is a blank Struts configuration file with an example
  welcome action/page and other commented sample elements.
 
- Tiles and the Struts Validator are configured using the factory defaults
- and are ready-to-use.
+ Struts Validator is configured using the factory defaults
+ and is ready-to-use.
 
  NOTE: If you have a generator tool to create the corresponding Java 
classes
  for you, you could include the details in the "form-bean" declarations.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2438) Validator plugin with DefaultForm doesn't work

 [ http://issues.apache.org/struts/browse/STR-2438?page=all ]
 
David Evans reopened STR-2438:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Validator plugin with DefaultForm doesn't work
> --
>
>  Key: STR-2438
>  URL: http://issues.apache.org/struts/browse/STR-2438
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Saju
> Assignee: David Evans

>
> Following is the code snippet from the DefaultForm class.
> public class DefaultForm extends ValidatorForm {
> protected final Log log = LogFactory.getLog(getClass());
> private Map dto = new HashMap();
> /**
>  * Sets a value into dtoMap. This value can be refered by Struts HTML tags
>  * with dto() syntax.
>  */
> public void setDto(String key, Object val) {
> dto.put(key, val);
> }
> /**
>  * Gets a value from dtoMap.
>  */
> public Object getDto(String key) {
> return dto.get(key);
> }
> /**
>  * Returns dtoMap
>  */
> public Map getDtoMap() {
> return dto;
> }
> public void reset(ActionMapping arg0, HttpServletRequest arg1) {
> super.reset(arg0, arg1);
> dto.clear();
> }
> /**
>  * Validates entries of dtoMap by Strut's validator.
>  * 
>  * @see org.apache.struts.action.ActionForm#validate
> (org.apache.struts.action.ActionMapping, 
> javax.servlet.http.HttpServletRequest)
>  */
> public ActionErrors validate(
> ActionMapping mapping,
> HttpServletRequest request) {
>  
> ServletContext application = getServlet().getServletContext();
> ActionErrors errors = new ActionErrors();
> 
> 
> 
> Validator validator = 
> Resources.initValidator(
> mapping.getAttribute(),
> dto,
> application,
> request,
> errors,
> page);
> try {
> validatorResults = validator.validate();
>   
> } catch (ValidatorException e) {
> log.error(e.getMessage(), e);
> }
>
> return errors;
> }
> But the validation is not working. It doesn't give any error but the 
> validation doesn't work also.
> Following are the config's file details
> struts-config.xml:
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>name = "loginForm" scope="request" input="/resources/jsp/login.jsp" 
> validate="true">
>   
>   
>   
> 
>   
>parameter="resources.prop.ApplicationResources"/>
>   
>value="validator-rules.xml,
>   validation.xml" />
>   
> 
> validation.xml:
> 
>   
> 
> 
> 
>   
>   
> 
>   
>
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2438) Validator plugin with DefaultForm doesn't work

 [ http://issues.apache.org/struts/browse/STR-2438?page=all ]
 
David Evans resolved STR-2438:
--

Resolution: Fixed

> Validator plugin with DefaultForm doesn't work
> --
>
>  Key: STR-2438
>  URL: http://issues.apache.org/struts/browse/STR-2438
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Saju
> Assignee: David Evans

>
> Following is the code snippet from the DefaultForm class.
> public class DefaultForm extends ValidatorForm {
> protected final Log log = LogFactory.getLog(getClass());
> private Map dto = new HashMap();
> /**
>  * Sets a value into dtoMap. This value can be refered by Struts HTML tags
>  * with dto() syntax.
>  */
> public void setDto(String key, Object val) {
> dto.put(key, val);
> }
> /**
>  * Gets a value from dtoMap.
>  */
> public Object getDto(String key) {
> return dto.get(key);
> }
> /**
>  * Returns dtoMap
>  */
> public Map getDtoMap() {
> return dto;
> }
> public void reset(ActionMapping arg0, HttpServletRequest arg1) {
> super.reset(arg0, arg1);
> dto.clear();
> }
> /**
>  * Validates entries of dtoMap by Strut's validator.
>  * 
>  * @see org.apache.struts.action.ActionForm#validate
> (org.apache.struts.action.ActionMapping, 
> javax.servlet.http.HttpServletRequest)
>  */
> public ActionErrors validate(
> ActionMapping mapping,
> HttpServletRequest request) {
>  
> ServletContext application = getServlet().getServletContext();
> ActionErrors errors = new ActionErrors();
> 
> 
> 
> Validator validator = 
> Resources.initValidator(
> mapping.getAttribute(),
> dto,
> application,
> request,
> errors,
> page);
> try {
> validatorResults = validator.validate();
>   
> } catch (ValidatorException e) {
> log.error(e.getMessage(), e);
> }
>
> return errors;
> }
> But the validation is not working. It doesn't give any error but the 
> validation doesn't work also.
> Following are the config's file details
> struts-config.xml:
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>name = "loginForm" scope="request" input="/resources/jsp/login.jsp" 
> validate="true">
>   
>   
>   
> 
>   
>parameter="resources.prop.ApplicationResources"/>
>   
>value="validator-rules.xml,
>   validation.xml" />
>   
> 
> validation.xml:
> 
>   
> 
> 
> 
>   
>   
> 
>   
>
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2438) Validator plugin with DefaultForm doesn't work

 [ http://issues.apache.org/struts/browse/STR-2438?page=all ]
 
David Evans closed STR-2438:



> Validator plugin with DefaultForm doesn't work
> --
>
>  Key: STR-2438
>  URL: http://issues.apache.org/struts/browse/STR-2438
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Saju
> Assignee: David Evans

>
> Following is the code snippet from the DefaultForm class.
> public class DefaultForm extends ValidatorForm {
> protected final Log log = LogFactory.getLog(getClass());
> private Map dto = new HashMap();
> /**
>  * Sets a value into dtoMap. This value can be refered by Struts HTML tags
>  * with dto() syntax.
>  */
> public void setDto(String key, Object val) {
> dto.put(key, val);
> }
> /**
>  * Gets a value from dtoMap.
>  */
> public Object getDto(String key) {
> return dto.get(key);
> }
> /**
>  * Returns dtoMap
>  */
> public Map getDtoMap() {
> return dto;
> }
> public void reset(ActionMapping arg0, HttpServletRequest arg1) {
> super.reset(arg0, arg1);
> dto.clear();
> }
> /**
>  * Validates entries of dtoMap by Strut's validator.
>  * 
>  * @see org.apache.struts.action.ActionForm#validate
> (org.apache.struts.action.ActionMapping, 
> javax.servlet.http.HttpServletRequest)
>  */
> public ActionErrors validate(
> ActionMapping mapping,
> HttpServletRequest request) {
>  
> ServletContext application = getServlet().getServletContext();
> ActionErrors errors = new ActionErrors();
> 
> 
> 
> Validator validator = 
> Resources.initValidator(
> mapping.getAttribute(),
> dto,
> application,
> request,
> errors,
> page);
> try {
> validatorResults = validator.validate();
>   
> } catch (ValidatorException e) {
> log.error(e.getMessage(), e);
> }
>
> return errors;
> }
> But the validation is not working. It doesn't give any error but the 
> validation doesn't work also.
> Following are the config's file details
> struts-config.xml:
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>name = "loginForm" scope="request" input="/resources/jsp/login.jsp" 
> validate="true">
>   
>   
>   
> 
>   
>parameter="resources.prop.ApplicationResources"/>
>   
>value="validator-rules.xml,
>   validation.xml" />
>   
> 
> validation.xml:
> 
>   
> 
> 
> 
>   
>   
> 
>   
>
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2381) [Shale] Enhancement to the Shale subview tag library component.

 [ http://issues.apache.org/struts/browse/STR-2381?page=all ]
 
David Evans reopened STR-2381:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> [Shale] Enhancement to the Shale subview tag library component.
> ---
>
>  Key: STR-2381
>  URL: http://issues.apache.org/struts/browse/STR-2381
>  Project: Struts Action 1
> Type: Improvement

>   Components: Shale
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Gary VanMatre
> Assignee: David Evans
> Priority: Minor
>  Attachments: ClayWeb.zip, ClayWeb.zip, ClayWeb.zip, clay-plugin-04-09.zip, 
> soda_example_war.zip, subview-example.zip
>
> The shale subview jsf component provides a post back method to the prerender 
> method on the ViewController.  The id attribute of the component is assumed 
> as 
> the managed bean name.  This method would be very useful for staging data for 
> the subview.  
> I would like to introduce a subclass of the subview tag that would allow 
> constructing fragments of a page using a XML definition.  Like tiles, the 
> metadata defining the subcomponent tree would support generalization 
> inheritances and also composition inheritance.  It would also allow a token 
> replacement feature of the binding EL so that the metadata describing the 
> construction of a subcomponent tree could be reused on multiple managed bean 
> names.
> I have a prototype of this component integrated in with Shale and using the 
> myfaces implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2381) [Shale] Enhancement to the Shale subview tag library component.

 [ http://issues.apache.org/struts/browse/STR-2381?page=all ]
 
David Evans resolved STR-2381:
--

Resolution: Fixed

> [Shale] Enhancement to the Shale subview tag library component.
> ---
>
>  Key: STR-2381
>  URL: http://issues.apache.org/struts/browse/STR-2381
>  Project: Struts Action 1
> Type: Improvement

>   Components: Shale
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Gary VanMatre
> Assignee: David Evans
> Priority: Minor
>  Attachments: ClayWeb.zip, ClayWeb.zip, ClayWeb.zip, clay-plugin-04-09.zip, 
> soda_example_war.zip, subview-example.zip
>
> The shale subview jsf component provides a post back method to the prerender 
> method on the ViewController.  The id attribute of the component is assumed 
> as 
> the managed bean name.  This method would be very useful for staging data for 
> the subview.  
> I would like to introduce a subclass of the subview tag that would allow 
> constructing fragments of a page using a XML definition.  Like tiles, the 
> metadata defining the subcomponent tree would support generalization 
> inheritances and also composition inheritance.  It would also allow a token 
> replacement feature of the binding EL so that the metadata describing the 
> construction of a subcomponent tree could be reused on multiple managed bean 
> names.
> I have a prototype of this component integrated in with Shale and using the 
> myfaces implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2381) [Shale] Enhancement to the Shale subview tag library component.

 [ http://issues.apache.org/struts/browse/STR-2381?page=all ]
 
David Evans closed STR-2381:



> [Shale] Enhancement to the Shale subview tag library component.
> ---
>
>  Key: STR-2381
>  URL: http://issues.apache.org/struts/browse/STR-2381
>  Project: Struts Action 1
> Type: Improvement

>   Components: Shale
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Gary VanMatre
> Assignee: David Evans
> Priority: Minor
>  Attachments: ClayWeb.zip, ClayWeb.zip, ClayWeb.zip, clay-plugin-04-09.zip, 
> soda_example_war.zip, subview-example.zip
>
> The shale subview jsf component provides a post back method to the prerender 
> method on the ViewController.  The id attribute of the component is assumed 
> as 
> the managed bean name.  This method would be very useful for staging data for 
> the subview.  
> I would like to introduce a subclass of the subview tag that would allow 
> constructing fragments of a page using a XML definition.  Like tiles, the 
> metadata defining the subcomponent tree would support generalization 
> inheritances and also composition inheritance.  It would also allow a token 
> replacement feature of the binding EL so that the metadata describing the 
> construction of a subcomponent tree could be reused on multiple managed bean 
> names.
> I have a prototype of this component integrated in with Shale and using the 
> myfaces implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2358) enhancement

 [ http://issues.apache.org/struts/browse/STR-2358?page=all ]
 
David Evans reopened STR-2358:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

>  enhancement
> -
>
>  Key: STR-2358
>  URL: http://issues.apache.org/struts/browse/STR-2358
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: Unknown
>  Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Graham Reeds
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3 Family
>  Attachments: BaseTag.java.diff, root.js, struts-html.tld
>
> This enhancement is to the  tag.  The reason for this enhancement
> request is that the base tag as it stands only points to the jsp file that it 
> is
> contained in.  However the base tag is exceptionally useful when pointed at 
> the
> root of the URL.
> My proposal is to add an optional attribute to the  tag. If the
> attribute is missing (or is set to false) then the tag acts as it normally 
> does.
>  With the addition of the attribute being set to "true" then the tag points to
> the root of the URL (ie //www.mysite.com/ or //locahost/mysite/).
> Currently the only way of getting this is currently to have a block of
> JavaScript code in every webpage and still needs to be set for each site and
> copied into everypage.
> tag: base
> attributes:
>  * root : Optional. Boolean value that determines whether the base tag points 
> at
> the root URL or the current page. The default is false.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2358) enhancement

 [ http://issues.apache.org/struts/browse/STR-2358?page=all ]
 
David Evans resolved STR-2358:
--

Resolution: Fixed

>  enhancement
> -
>
>  Key: STR-2358
>  URL: http://issues.apache.org/struts/browse/STR-2358
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: Unknown
>  Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Graham Reeds
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3 Family
>  Attachments: BaseTag.java.diff, root.js, struts-html.tld
>
> This enhancement is to the  tag.  The reason for this enhancement
> request is that the base tag as it stands only points to the jsp file that it 
> is
> contained in.  However the base tag is exceptionally useful when pointed at 
> the
> root of the URL.
> My proposal is to add an optional attribute to the  tag. If the
> attribute is missing (or is set to false) then the tag acts as it normally 
> does.
>  With the addition of the attribute being set to "true" then the tag points to
> the root of the URL (ie //www.mysite.com/ or //locahost/mysite/).
> Currently the only way of getting this is currently to have a block of
> JavaScript code in every webpage and still needs to be set for each site and
> copied into everypage.
> tag: base
> attributes:
>  * root : Optional. Boolean value that determines whether the base tag points 
> at
> the root URL or the current page. The default is false.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2342) Escape double quotes in JavascriptValidatorTag

 [ http://issues.apache.org/struts/browse/STR-2342?page=all ]
 
David Evans resolved STR-2342:
--

Resolution: Fixed

> Escape double quotes in JavascriptValidatorTag
> --
>
>  Key: STR-2342
>  URL: http://issues.apache.org/struts/browse/STR-2342
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: All
> Platform: All
> Reporter: chng
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: JavascriptValidatorTag.java, struts-33238.patch
>
> To escape double quotes when generating dynamic javascript in 
> JavascriptValidatorTag, to allow the evaluation of javascript expressions. 
> This could set the stage for a Rhino-like Validator, in the future.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2342) Escape double quotes in JavascriptValidatorTag

 [ http://issues.apache.org/struts/browse/STR-2342?page=all ]
 
David Evans reopened STR-2342:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Escape double quotes in JavascriptValidatorTag
> --
>
>  Key: STR-2342
>  URL: http://issues.apache.org/struts/browse/STR-2342
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: All
> Platform: All
> Reporter: chng
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: JavascriptValidatorTag.java, struts-33238.patch
>
> To escape double quotes when generating dynamic javascript in 
> JavascriptValidatorTag, to allow the evaluation of javascript expressions. 
> This could set the stage for a Rhino-like Validator, in the future.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2358) enhancement

 [ http://issues.apache.org/struts/browse/STR-2358?page=all ]
 
David Evans closed STR-2358:



>  enhancement
> -
>
>  Key: STR-2358
>  URL: http://issues.apache.org/struts/browse/STR-2358
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: Unknown
>  Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Graham Reeds
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.3 Family
>  Attachments: BaseTag.java.diff, root.js, struts-html.tld
>
> This enhancement is to the  tag.  The reason for this enhancement
> request is that the base tag as it stands only points to the jsp file that it 
> is
> contained in.  However the base tag is exceptionally useful when pointed at 
> the
> root of the URL.
> My proposal is to add an optional attribute to the  tag. If the
> attribute is missing (or is set to false) then the tag acts as it normally 
> does.
>  With the addition of the attribute being set to "true" then the tag points to
> the root of the URL (ie //www.mysite.com/ or //locahost/mysite/).
> Currently the only way of getting this is currently to have a block of
> JavaScript code in every webpage and still needs to be set for each site and
> copied into everypage.
> tag: base
> attributes:
>  * root : Optional. Boolean value that determines whether the base tag points 
> at
> the root URL or the current page. The default is false.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2342) Escape double quotes in JavascriptValidatorTag

 [ http://issues.apache.org/struts/browse/STR-2342?page=all ]
 
David Evans closed STR-2342:



> Escape double quotes in JavascriptValidatorTag
> --
>
>  Key: STR-2342
>  URL: http://issues.apache.org/struts/browse/STR-2342
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: All
> Platform: All
> Reporter: chng
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: JavascriptValidatorTag.java, struts-33238.patch
>
> To escape double quotes when generating dynamic javascript in 
> JavascriptValidatorTag, to allow the evaluation of javascript expressions. 
> This could set the stage for a Rhino-like Validator, in the future.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bug report for Struts [2006/04/23]

I'm sure there is a way, but my exploring and googling isn't turning up 
anything.  Any JIRA experts out there?


Don

Ted Husted wrote:

On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:
  

Heh, guess we'll need to turn that off :)



I should already know this, but does JIRA have an automatic email
report that we can turn on?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[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]

Re: Bug report for Struts [2006/04/23]

2006-04-24 Thread Martin Cooper

On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> I'm sure there is a way, but my exploring and googling isn't turning up
> anything.  Any JIRA experts out there?


There is definitely a way to do this - there's a weekly report of open infra
issues that gets sent to that list. Presumably someone on infra@ would know
how to enable it. ;-)

--
Martin Cooper


Don
>
> Ted Husted wrote:
> > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> >> Heh, guess we'll need to turn that off :)
> >>
> >
> > I should already know this, but does JIRA have an automatic email
> > report that we can turn on?
> >
> > -Ted.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[action1] Commons Validator version?

2006-04-24 Thread Wendy Smoak

Should we move to Commons Validator 1.3.0 for Struts Action?

--
Wendy

-
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]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Bob Lee

I'm not sure two major releases is what's best for users.

- If SAF2 is going to be the same as WW2, why have it at all? I think
it will confuse users unnecessarily.
- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and SAF2.
- Some users will migrate to SAF2 and then will have to migrate again to SAF3.
- People will think we're incompetent and disorganized and that we
care more about playing than supporting users based on the fact that
we completely redesigned our framework twice in such a short period of
time (SAF1 -> SAF2 -> SAF3).

I think we're overestimating the amount of effort it will take to do
this right. Designing a clean API that we can support for the next 5
years should be our #1 priority. We can do a minimal amount of work on
the implementation so we can release ASAP and clean it up later.

Bob

On 4/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On the RoughSpots page,
>
> * http://wiki.apache.org/struts/RoughSpots
>
> there's a reference to Action 3.x that speaks as if it's far away.
> That doesn't need to be the case. We can create a branch for "Action
> Next" or "Ti2" as soon as the code comes down from the incubator. We
> did the same for Action 1.2 and Action 1.3. We've continued to
> maintain and extend Action 1.2, while more agressive changes where
> made to Action 1.3.
>
> The original proposal was for Ti to happen in two phases. The first
> phase was to release Action 2.0 based on WebWork 2.2 by making only
> necessary and prudent changes. More aggressive changes were to happen
> in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
> 2 might be Action 2.1 or Action 3.x. That's a decision we can make
> later.
>
> Personally, I don't believe the release of Action 2.0 is going to
> create a migration stampede. Some people who are starting new projects
> may decide to use Action 2 instead of Action 1. But the people I know
> won't bother to migrate existing applications. At least not anytime
> soon.
>
> Right now, some teams that are looking forward to Action 2 are getting
> started with WebWork 2.2 now. I suggest that Job One should be to get
> a current release out there that we can use while we work on Phase 2.
> Otherwise, we could easily find ourself maintaining WebWork 2.x at
> OpenSymphony and then having to mirror any changes in Action 2.x at
> Apache Struts.
>
> I think it's important to first create a stable release of Action 2.0
> as the direct successor to WebWork 2.2, and then focus on the more
> aggressive changes slated for Phase 2. We can make it very clear to
> people that "Phase 2" is in the works, so people who don't want to
> migrate more than once can make an informed decision.
>
> Thoughts?
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action1] Commons Validator version?


Wendy Smoak wrote:

Should we move to Commons Validator 1.3.0 for Struts Action?

+1 as long as it is stable and won't hold up the release.

Don


--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

If we can get this "clean API" in by July, then I'm fine with it being in SAF 2. The bottom line is I think we need a
GA release by August, but it is important to remember a lot more goes into a release than just coding - build processes,
release processes, documentation, testing, etc. This type of stuff is hard to get folks to sign up for, so it usually
ends up dragging on. Unfortunately, releases aren't as simple as a code snapshot :/

I think realistically we'll be sifting through the rough spots document, picking some and discarding others, then
implementing them in a staggered fashion. Introducing a strong annotation support in 2.1, for example, is a more
realistic goal, than trying to quickly get it down and push it in for the August release.

Don

Bob Lee wrote:

I'm not sure two major releases is what's best for users.

- If SAF2 is going to be the same as WW2, why have it at all? I think
it will confuse users unnecessarily.
- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and SAF2.
- Some users will migrate to SAF2 and then will have to migrate again to SAF3.
- People will think we're incompetent and disorganized and that we
care more about playing than supporting users based on the fact that
we completely redesigned our framework twice in such a short period of
time (SAF1 -> SAF2 -> SAF3).

I think we're overestimating the amount of effort it will take to do
this right. Designing a clean API that we can support for the next 5
years should be our #1 priority. We can do a minimal amount of work on
the implementation so we can release ASAP and clean it up later.

Bob

On 4/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:

On the RoughSpots page,

* http://wiki.apache.org/struts/RoughSpots

there's a reference to Action 3.x that speaks as if it's far away.
That doesn't need to be the case. We can create a branch for "Action
Next" or "Ti2" as soon as the code comes down from the incubator. We
did the same for Action 1.2 and Action 1.3. We've continued to
maintain and extend Action 1.2, while more agressive changes where
made to Action 1.3.

The original proposal was for Ti to happen in two phases. The first
phase was to release Action 2.0 based on WebWork 2.2 by making only
necessary and prudent changes. More aggressive changes were to happen
in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
2 might be Action 2.1 or Action 3.x. That's a decision we can make
later.

Personally, I don't believe the release of Action 2.0 is going to
create a migration stampede. Some people who are starting new projects
may decide to use Action 2 instead of Action 1. But the people I know
won't bother to migrate existing applications. At least not anytime
soon.

Right now, some teams that are looking forward to Action 2 are getting
started with WebWork 2.2 now. I suggest that Job One should be to get
a current release out there that we can use while we work on Phase 2.
Otherwise, we could easily find ourself maintaining WebWork 2.x at
OpenSymphony and then having to mirror any changes in Action 2.x at
Apache Struts.

I think it's important to first create a stable release of Action 2.0
as the direct successor to WebWork 2.2, and then focus on the more
aggressive changes slated for Phase 2. We can make it very clear to
people that "Phase 2" is in the works, so people who don't want to
migrate more than once can make an informed decision.

Thoughts?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Gabe


I agree with Bob on all his points below. It wouldn't look good to do one 
radical change of the API and then another. If we want to do a transitional 
release maybe the way to do it as a 1.9 release similar to how Lucene did it or 
a 2.0 "preview" release.

Also, if SAF 2 will be radically different from WW2, we might want to keep 
opensymphony open so bug fixes can be submitted to WW as well, especially now 
that people are looking more at using WW2.

Gabe 

- Original Message 
From: Bob Lee <[EMAIL PROTECTED]>
To: Struts Developers List ; [EMAIL PROTECTED]
Sent: Monday, April 24, 2006 1:34:59 PM
Subject: Re: [action2] Action Next++ (Ti Phase 2)

I'm not sure two major releases is what's best for users.

- If SAF2 is going to be the same as WW2, why have it at all? I think
it will confuse users unnecessarily.
- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and SAF2.
- Some users will migrate to SAF2 and then will have to migrate again to SAF3.
- People will think we're incompetent and disorganized and that we
care more about playing than supporting users based on the fact that
we completely redesigned our framework twice in such a short period of
time (SAF1 -> SAF2 -> SAF3).

I think we're overestimating the amount of effort it will take to do
this right. Designing a clean API that we can support for the next 5
years should be our #1 priority. We can do a minimal amount of work on
the implementation so we can release ASAP and clean it up later.

Bob

On 4/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On the RoughSpots page,
>
> * http://wiki.apache.org/struts/RoughSpots
>
> there's a reference to Action 3.x that speaks as if it's far away.
> That doesn't need to be the case. We can create a branch for "Action
> Next" or "Ti2" as soon as the code comes down from the incubator. We
> did the same for Action 1.2 and Action 1.3. We've continued to
> maintain and extend Action 1.2, while more agressive changes where
> made to Action 1.3.
>
> The original proposal was for Ti to happen in two phases. The first
> phase was to release Action 2.0 based on WebWork 2.2 by making only
> necessary and prudent changes. More aggressive changes were to happen
> in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
> 2 might be Action 2.1 or Action 3.x. That's a decision we can make
> later.
>
> Personally, I don't believe the release of Action 2.0 is going to
> create a migration stampede. Some people who are starting new projects
> may decide to use Action 2 instead of Action 1. But the people I know
> won't bother to migrate existing applications. At least not anytime
> soon.
>
> Right now, some teams that are looking forward to Action 2 are getting
> started with WebWork 2.2 now. I suggest that Job One should be to get
> a current release out there that we can use while we work on Phase 2.
> Otherwise, we could easily find ourself maintaining WebWork 2.x at
> OpenSymphony and then having to mirror any changes in Action 2.x at
> Apache Struts.
>
> I think it's important to first create a stable release of Action 2.0
> as the direct successor to WebWork 2.2, and then focus on the more
> aggressive changes slated for Phase 2. We can make it very clear to
> people that "Phase 2" is in the works, so people who don't want to
> migrate more than once can make an informed decision.
>
> Thoughts?
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Joe Germuska


At 10:34 AM -0700 4/24/06, Bob Lee wrote:

I'm not sure two major releases is what's best for users.

- If SAF2 is going to be the same as WW2, why have it at all? I think
it will confuse users unnecessarily.
- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and SAF2.
- Some users will migrate to SAF2 and then will have to migrate again to SAF3.
- People will think we're incompetent and disorganized and that we
care more about playing than supporting users based on the fact that
we completely redesigned our framework twice in such a short period of
time (SAF1 -> SAF2 -> SAF3).

I think we're overestimating the amount of effort it will take to do
this right. Designing a clean API that we can support for the next 5
years should be our #1 priority. We can do a minimal amount of work on
the implementation so we can release ASAP and clean it up later.


I'm inclined to agree with Bob here.  At this point, I think that the 
first release of SAF2 should be taking the stage as more than just 
WebWork 2.x with renamed packages.  It doesn't need to be radically 
different, but it should be more than that.


Joe

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Martin Cooper

On 4/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> At 10:34 AM -0700 4/24/06, Bob Lee wrote:
> >I'm not sure two major releases is what's best for users.
> >
> >- If SAF2 is going to be the same as WW2, why have it at all? I think
> >it will confuse users unnecessarily.
> >- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and
> SAF2.
> >- Some users will migrate to SAF2 and then will have to migrate again to
> SAF3.
> >- People will think we're incompetent and disorganized and that we
> >care more about playing than supporting users based on the fact that
> >we completely redesigned our framework twice in such a short period of
> >time (SAF1 -> SAF2 -> SAF3).
> >
> >I think we're overestimating the amount of effort it will take to do
> >this right. Designing a clean API that we can support for the next 5
> >years should be our #1 priority. We can do a minimal amount of work on
> >the implementation so we can release ASAP and clean it up later.
>
> I'm inclined to agree with Bob here.  At this point, I think that the
> first release of SAF2 should be taking the stage as more than just
> WebWork 2.x with renamed packages.  It doesn't need to be radically
> different, but it should be more than that.


+1

--
Martin Cooper


Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED] * http://blog.germuska.com
>
> "You really can't burn anything out by trying something new, and
> even if you can burn it out, it can be fixed.  Try something new."
> -- Robert Moog
>
> -
> 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  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 rea

[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.

Re: [action2] Action Next++ (Ti Phase 2)

2006-04-24 Thread Bob Lee

I think that's a realistic goal. I'm all for starting with a
manageable subset of features in the first release and incrementally
introducing more features in a backward compatible way in followup
releases.

Bob

On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
> If we can get this "clean API" in by July, then I'm fine with it being in SAF 
> 2.  The bottom line is I think we need a
> GA release by August, but it is important to remember a lot more goes into a 
> release than just coding - build processes,
> release processes, documentation, testing, etc.  This type of stuff is hard 
> to get folks to sign up for, so it usually
> ends up dragging on.  Unfortunately, releases aren't as simple as a code 
> snapshot :/
>
> I think realistically we'll be sifting through the rough spots document, 
> picking some and discarding others, then
> implementing them in a staggered fashion.  Introducing a strong annotation 
> support in 2.1, for example, is a more
> realistic goal, than trying to quickly get it down and push it in for the 
> August release.
>
> Don
>
> Bob Lee wrote:
> > I'm not sure two major releases is what's best for users.
> >
> > - If SAF2 is going to be the same as WW2, why have it at all? I think
> > it will confuse users unnecessarily.
> > - We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and 
> > SAF2.
> > - Some users will migrate to SAF2 and then will have to migrate again to 
> > SAF3.
> > - People will think we're incompetent and disorganized and that we
> > care more about playing than supporting users based on the fact that
> > we completely redesigned our framework twice in such a short period of
> > time (SAF1 -> SAF2 -> SAF3).
> >
> > I think we're overestimating the amount of effort it will take to do
> > this right. Designing a clean API that we can support for the next 5
> > years should be our #1 priority. We can do a minimal amount of work on
> > the implementation so we can release ASAP and clean it up later.
> >
> > Bob
> >
> > On 4/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> >> On the RoughSpots page,
> >>
> >> * http://wiki.apache.org/struts/RoughSpots
> >>
> >> there's a reference to Action 3.x that speaks as if it's far away.
> >> That doesn't need to be the case. We can create a branch for "Action
> >> Next" or "Ti2" as soon as the code comes down from the incubator. We
> >> did the same for Action 1.2 and Action 1.3. We've continued to
> >> maintain and extend Action 1.2, while more agressive changes where
> >> made to Action 1.3.
> >>
> >> The original proposal was for Ti to happen in two phases. The first
> >> phase was to release Action 2.0 based on WebWork 2.2 by making only
> >> necessary and prudent changes. More aggressive changes were to happen
> >> in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
> >> 2 might be Action 2.1 or Action 3.x. That's a decision we can make
> >> later.
> >>
> >> Personally, I don't believe the release of Action 2.0 is going to
> >> create a migration stampede. Some people who are starting new projects
> >> may decide to use Action 2 instead of Action 1. But the people I know
> >> won't bother to migrate existing applications. At least not anytime
> >> soon.
> >>
> >> Right now, some teams that are looking forward to Action 2 are getting
> >> started with WebWork 2.2 now. I suggest that Job One should be to get
> >> a current release out there that we can use while we work on Phase 2.
> >> Otherwise, we could easily find ourself maintaining WebWork 2.x at
> >> OpenSymphony and then having to mirror any changes in Action 2.x at
> >> Apache Struts.
> >>
> >> I think it's important to first create a stable release of Action 2.0
> >> as the direct successor to WebWork 2.2, and then focus on the more
> >> aggressive changes slated for Phase 2. We can make it very clear to
> >> people that "Phase 2" is in the works, so people who don't want to
> >> migrate more than once can make an informed decision.
> >>
> >> Thoughts?
> >>
> >> -Ted.
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2292) Wild Card Mapping - lowercase name for form beans

 [ http://issues.apache.org/struts/browse/STR-2292?page=all ]
 
David Evans reopened STR-2292:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Wild Card Mapping - lowercase name for form beans
> -
>
>  Key: STR-2292
>  URL: http://issues.apache.org/struts/browse/STR-2292
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Sujay D'Souza
> Assignee: David Evans

>
> Having a problem with Wildcard mapping. There is a problem with case and form
> beans, especially if used according to the example located on the doc's
> http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards
> when specifing the "name" attribute in the action mapping i.e. when using a
> wildcard, and you specify a lowercase form name bean, in actuality it is 
> looking
> for a formbean name in uppercase when i turned on logging. The example too 
> uses
> a lowercase form bean name - which is the convention for class names.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (STR-2292) Wild Card Mapping - lowercase name for form beans

 [ http://issues.apache.org/struts/browse/STR-2292?page=all ]
 
David Evans resolved STR-2292:
--

Resolution: Fixed

> Wild Card Mapping - lowercase name for form beans
> -
>
>  Key: STR-2292
>  URL: http://issues.apache.org/struts/browse/STR-2292
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Sujay D'Souza
> Assignee: David Evans

>
> Having a problem with Wildcard mapping. There is a problem with case and form
> beans, especially if used according to the example located on the doc's
> http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards
> when specifing the "name" attribute in the action mapping i.e. when using a
> wildcard, and you specify a lowercase form name bean, in actuality it is 
> looking
> for a formbean name in uppercase when i turned on logging. The example too 
> uses
> a lowercase form bean name - which is the convention for class names.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2292) Wild Card Mapping - lowercase name for form beans

 [ http://issues.apache.org/struts/browse/STR-2292?page=all ]
 
David Evans closed STR-2292:



> Wild Card Mapping - lowercase name for form beans
> -
>
>  Key: STR-2292
>  URL: http://issues.apache.org/struts/browse/STR-2292
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.2.4
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Sujay D'Souza
> Assignee: David Evans

>
> Having a problem with Wildcard mapping. There is a problem with case and form
> beans, especially if used according to the example located on the doc's
> http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards
> when specifing the "name" attribute in the action mapping i.e. when using a
> wildcard, and you specify a lowercase form name bean, in actuality it is 
> looking
> for a formbean name in uppercase when i turned on logging. The example too 
> uses
> a lowercase form bean name - which is the convention for class names.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2301) format clause

 [ http://issues.apache.org/struts/browse/STR-2301?page=all ]
 
David Evans closed STR-2301:


Resolution: Fixed

>  format clause
> --
>
>  Key: STR-2301
>  URL: http://issues.apache.org/struts/browse/STR-2301
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Bruno Melloni
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> This is probably a trivial documentation fix.
>  relies heavily on the format clause for formatting non-String
> entries.  How to use a format (either in the tag, or in the message resources)
> is clearly explained.
> What is not clear is the spec for format clauses.  Examples can be found on 
> the
> net for dates and $ types, but it is nearly impossible to locate a complete
> reference for the format clause "characters" and combination rules.
> This probably already exists - somewhere - so all that is needed is a link in
> the  docs that points to it.  
> My guess is that this is a 10 minute job, assuming such docs already exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2301) format clause

 [ http://issues.apache.org/struts/browse/STR-2301?page=all ]
 
David Evans reopened STR-2301:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

>  format clause
> --
>
>  Key: STR-2301
>  URL: http://issues.apache.org/struts/browse/STR-2301
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: Unknown
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Bruno Melloni
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> This is probably a trivial documentation fix.
>  relies heavily on the format clause for formatting non-String
> entries.  How to use a format (either in the tag, or in the message resources)
> is clearly explained.
> What is not clear is the spec for format clauses.  Examples can be found on 
> the
> net for dates and $ types, but it is nearly impossible to locate a complete
> reference for the format clause "characters" and combination rules.
> This probably already exists - somewhere - so all that is needed is a link in
> the  docs that points to it.  
> My guess is that this is a 10 minute job, assuming such docs already exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2269) tag renders incorrect HTML 4.01 strict when using token

 [ http://issues.apache.org/struts/browse/STR-2269?page=all ]
 
David Evans reopened STR-2269:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

>  tag renders incorrect HTML 4.01 strict when using token
> ---
>
>  Key: STR-2269
>  URL: http://issues.apache.org/struts/browse/STR-2269
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.4
>  Environment: Operating System: All
> Platform: All
> Reporter: Brian Preuß
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.2 Family

>
> When you are using the  tag with the transaction token, the tag
> renders the following html:
>  type="hidden"
> name="org.apache.struts.taglib.html.TOKEN" 
> value="d8fb5d4dbc6d379f9dc65d25d55d337e">
> 
> 
> When you validate such a html code against the strict doctype as in
>  "http://www.w3.org/TR/html4/strict.dtd";>
> you will get an error:
> Error: element INPUT not allowed here; possible cause is an inline element
> containing a block-level element
> A possible solution could be to add another attribute for the form tag like
> "strict" with values true|false which would trigger the generation of a dummy
> div-block just like
> ...
> This html would validate against the strict doctype.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2269) tag renders incorrect HTML 4.01 strict when using token

 [ http://issues.apache.org/struts/browse/STR-2269?page=all ]
 
David Evans closed STR-2269:


Resolution: Fixed

>  tag renders incorrect HTML 4.01 strict when using token
> ---
>
>  Key: STR-2269
>  URL: http://issues.apache.org/struts/browse/STR-2269
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.2.4
>  Environment: Operating System: All
> Platform: All
> Reporter: Brian Preuß
> Assignee: David Evans
> Priority: Minor
>  Fix For: 1.2 Family

>
> When you are using the  tag with the transaction token, the tag
> renders the following html:
>  type="hidden"
> name="org.apache.struts.taglib.html.TOKEN" 
> value="d8fb5d4dbc6d379f9dc65d25d55d337e">
> 
> 
> When you validate such a html code against the strict doctype as in
>  "http://www.w3.org/TR/html4/strict.dtd";>
> you will get an error:
> Error: element INPUT not allowed here; possible cause is an inline element
> containing a block-level element
> A possible solution could be to add another attribute for the form tag like
> "strict" with values true|false which would trigger the generation of a dummy
> div-block just like
> ...
> This html would validate against the strict doctype.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2267) org.apache.struts.upload.CommonsMultipartRequestHandler not found sometimes

 [ http://issues.apache.org/struts/browse/STR-2267?page=all ]
 
David Evans reopened STR-2267:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> org.apache.struts.upload.CommonsMultipartRequestHandler not found sometimes
> ---
>
>  Key: STR-2267
>  URL: http://issues.apache.org/struts/browse/STR-2267
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.1 Final
>  Environment: Operating System: All
> Platform: PC
> Reporter: Ars
> Assignee: David Evans

>
> My Struts-based application is being tested now and sometimes (don`t know 
> when) 
> I receive such an exception:
> javax.servlet.ServletException: Cannot find multipart class 
> "org.apache.struts.
> upload.CommonsMultipartRequestHandler", exception: org.apache.struts.upload.
> CommonsMultipartRequestHandler
>   at 
> org.apache.struts.util.RequestUtils.getMultipartHandler(RequestUtils.java:
> 1320)
>   at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1194)
>   at 
> org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.
> java:821)
>   at 
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
>   at 
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
>   at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:248)
>   at org.apache.catalina.core.ApplicationFilterChain.
> doFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
> java:259)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
> java:191)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2491)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 180)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
> java:171)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:641)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 172)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:641)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:174)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardEngine.invoke(StandardEngine.java:376)
>   at 
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:224)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:618)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:555)
>   at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.
> processConnection(Http11Protocol.java:402)
>   at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:586)
>   at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.
> java:619)
>   at java.lang.Thread.run(Thread.java:534)
> I have no idea why and at what contitions is it thrown. 99% times everything 
> works fine but SOMETIMES it happens. This exception is thrown to the client 
> browser so it is critical to me, as I have no opportunity to catch it.

-- 
This message is automatically generated by JIRA.
-
If you think i

[jira] Closed: (STR-2267) org.apache.struts.upload.CommonsMultipartRequestHandler not found sometimes

 [ http://issues.apache.org/struts/browse/STR-2267?page=all ]
 
David Evans closed STR-2267:


Resolution: Fixed

> org.apache.struts.upload.CommonsMultipartRequestHandler not found sometimes
> ---
>
>  Key: STR-2267
>  URL: http://issues.apache.org/struts/browse/STR-2267
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.1 Final
>  Environment: Operating System: All
> Platform: PC
> Reporter: Ars
> Assignee: David Evans

>
> My Struts-based application is being tested now and sometimes (don`t know 
> when) 
> I receive such an exception:
> javax.servlet.ServletException: Cannot find multipart class 
> "org.apache.struts.
> upload.CommonsMultipartRequestHandler", exception: org.apache.struts.upload.
> CommonsMultipartRequestHandler
>   at 
> org.apache.struts.util.RequestUtils.getMultipartHandler(RequestUtils.java:
> 1320)
>   at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1194)
>   at 
> org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.
> java:821)
>   at 
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
>   at 
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
>   at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:248)
>   at org.apache.catalina.core.ApplicationFilterChain.
> doFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
> java:259)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
> java:191)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2491)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 180)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
> java:171)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:641)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 172)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:641)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:174)
>   at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
> invokeNext(StandardPipeline.java:643)
>   at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>   at 
> org.apache.catalina.core.StandardEngine.invoke(StandardEngine.java:376)
>   at 
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:224)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:618)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:555)
>   at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.
> processConnection(Http11Protocol.java:402)
>   at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:586)
>   at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.
> java:619)
>   at java.lang.Thread.run(Thread.java:534)
> I have no idea why and at what contitions is it thrown. 99% times everything 
> works fine but SOMETIMES it happens. This exception is thrown to the client 
> browser so it is critical to me, as I have no opportunity to catch it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the admin

[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]

[jira] Reopened: (STR-2191) Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26

 [ http://issues.apache.org/struts/browse/STR-2191?page=all ]
 
David Evans reopened STR-2191:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26
> --
>
>  Key: STR-2191
>  URL: http://issues.apache.org/struts/browse/STR-2191
>  Project: Struts Action 1
> Type: Bug

>   Components: Faces
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Piero Colagrosso
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> I am running the struts-faces2 example (Struts+Faces+Tiles) via the
> struts-faces2.war file which is included with the struts-faces distribution
> (nightly build).
> The WAR file seems to deploy fine and I don't get any error messages. I am 
> also
> able to use the 'Register' function without any errors.
> However, when I try to access the 'Log On' function I obtain the stack trace
> listed below.  I am running Tomcat 5.0.26 (bundled within JBoss 3.2.5) on Red
> Hat Fedora.  All our existing 'pure' Struts applications run fine in the exact
> same environment.   I am also using August 31st nightly build of struts-faces.
> Regards,
>Piero
> __
> Stack Trace:
> type Exception report
> message
> description The server encountered an internal error () that prevented it from
> fulfilling this request.
> exception
> org.apache.jasper.JasperException
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:372)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
>   
> com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
>   com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
>   com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
>   javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
> root cause
> java.lang.NullPointerException
>   
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683)
>   javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324)
>   javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591)
>   javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478)
>   org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132)
>   org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104)
>   org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
>   
> com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
>   com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
>   com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
>   javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
> ___
> The full stack trace reads as follows:
> 2004-09-02 09:36:22,886 472097 ERROR [org.jboss.web.localhost.Engine]
> (http-0.0.0.0-8180-Processor2 4:) ApplicationDispatcher[/struts-faces2]
> Servlet.service() for servlet jsp threw exception
> java.lang.NullPointerException
> at
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683)
> at javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324)
> at 
> javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591)
> at 
> javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478)
> at org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132)
> at org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104)
> at org.apache.jasper.runtime.Http

[jira] Closed: (STR-2191) Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26

 [ http://issues.apache.org/struts/browse/STR-2191?page=all ]
 
David Evans closed STR-2191:


Resolution: Fixed

> Stack trace when running WAR File of struts-faces2 example - Tomcat 5.0.26
> --
>
>  Key: STR-2191
>  URL: http://issues.apache.org/struts/browse/STR-2191
>  Project: Struts Action 1
> Type: Bug

>   Components: Faces
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Piero Colagrosso
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> I am running the struts-faces2 example (Struts+Faces+Tiles) via the
> struts-faces2.war file which is included with the struts-faces distribution
> (nightly build).
> The WAR file seems to deploy fine and I don't get any error messages. I am 
> also
> able to use the 'Register' function without any errors.
> However, when I try to access the 'Log On' function I obtain the stack trace
> listed below.  I am running Tomcat 5.0.26 (bundled within JBoss 3.2.5) on Red
> Hat Fedora.  All our existing 'pure' Struts applications run fine in the exact
> same environment.   I am also using August 31st nightly build of struts-faces.
> Regards,
>Piero
> __
> Stack Trace:
> type Exception report
> message
> description The server encountered an internal error () that prevented it from
> fulfilling this request.
> exception
> org.apache.jasper.JasperException
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:372)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
>   
> com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
>   com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
>   com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
>   javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
> root cause
> java.lang.NullPointerException
>   
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683)
>   javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324)
>   javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591)
>   javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478)
>   org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132)
>   org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104)
>   org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>   
> com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
>   
> com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
>   
> com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
>   com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
>   com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
>   javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
> ___
> The full stack trace reads as follows:
> 2004-09-02 09:36:22,886 472097 ERROR [org.jboss.web.localhost.Engine]
> (http-0.0.0.0-8180-Processor2 4:) ApplicationDispatcher[/struts-faces2]
> Servlet.service() for servlet jsp threw exception
> java.lang.NullPointerException
> at
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:683)
> at javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:324)
> at 
> javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:591)
> at 
> javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:478)
> at org.apache.jsp.logon_jsp._jspx_meth_s_errors_0(logon_jsp.java:132)
> at org.apache.jsp.logon_jsp._jspService(logon_jsp.java:104)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
>

Re: Bug report for Struts [2006/04/23]

2006-04-24 Thread Paul Speed

I think filters is the way to do this.  Create a filter and then have it 
e-mail itself every so often.

-Paul

Martin Cooper wrote:


On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote:


I'm sure there is a way, but my exploring and googling isn't turning up
anything.  Any JIRA experts out there?




There is definitely a way to do this - there's a weekly report of open infra
issues that gets sent to that list. Presumably someone on infra@ would know
how to enable it. ;-)

--
Martin Cooper


Don


Ted Husted wrote:


On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote:



Heh, guess we'll need to turn that off :)



I should already know this, but does JIRA have an automatic email
report that we can turn on?

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2168) Struts-Tiles-JSF-Integration SOMETIMES creates blank pages

 [ http://issues.apache.org/struts/browse/STR-2168?page=all ]
 
David Evans reopened STR-2168:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Struts-Tiles-JSF-Integration SOMETIMES creates blank pages
> --
>
>  Key: STR-2168
>  URL: http://issues.apache.org/struts/browse/STR-2168
>  Project: Struts Action 1
> Type: Bug

>   Components: Faces
> Versions: 1.1 Final
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Alexander Manes
> Assignee: David Evans
>  Fix For: 1.2 Family
>  Attachments: struts-faces-tiles-blank-page-error.zip, struts-faces.fix.jar
>
> I integrated Struts, Tiles and JavaServer Faces in a webapp (development on 
> Tomcat 5.0.27, WinXP, j2sdk1.4.2_04).
> Form submissions to struts actions  work 
> without problems, but the following code sometimes generates blank pages:
> 
> 
> 
> 
> When I hit such a link for the first time, it usually works. When I hit 
> another one (e.g. with different target) it's likely to fail, but I can hit 
> RELOAD and I get a correct response. Usually the next time a similar link 
> fails, there's no way to get a response from the server until I reload the 
> whole webapp!
> When I get the blank page, there is absolutely no Exception (not on the 
> console, not in Tomcat logs, not on the page). The page is just blank!
> Debugging showed that my struts action scrollarticles.do or any other action 
> that is called is executed correctly, but no response is rendered to the 
> client browser (there is no HTML source that the browser could display, it's 
> not just an error in the HTML output).
> Also I get the blank page more often on IE6 than on Opera 7, but both 
> browsers 
> are configured to load a page upon every single request (not loading from 
> local cache).
> Is this a bug or am I totally wrong on the use of h:outputLink???
> I know that s:form logically submits to a struts action, but the rendered 
> HTML 
> submits to layout.faces because I'm using Tiles. Is it just wrong call a .do 
> directly???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2168) Struts-Tiles-JSF-Integration SOMETIMES creates blank pages

 [ http://issues.apache.org/struts/browse/STR-2168?page=all ]
 
David Evans closed STR-2168:


Resolution: Fixed

> Struts-Tiles-JSF-Integration SOMETIMES creates blank pages
> --
>
>  Key: STR-2168
>  URL: http://issues.apache.org/struts/browse/STR-2168
>  Project: Struts Action 1
> Type: Bug

>   Components: Faces
> Versions: 1.1 Final
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Alexander Manes
> Assignee: David Evans
>  Fix For: 1.2 Family
>  Attachments: struts-faces-tiles-blank-page-error.zip, struts-faces.fix.jar
>
> I integrated Struts, Tiles and JavaServer Faces in a webapp (development on 
> Tomcat 5.0.27, WinXP, j2sdk1.4.2_04).
> Form submissions to struts actions  work 
> without problems, but the following code sometimes generates blank pages:
> 
> 
> 
> 
> When I hit such a link for the first time, it usually works. When I hit 
> another one (e.g. with different target) it's likely to fail, but I can hit 
> RELOAD and I get a correct response. Usually the next time a similar link 
> fails, there's no way to get a response from the server until I reload the 
> whole webapp!
> When I get the blank page, there is absolutely no Exception (not on the 
> console, not in Tomcat logs, not on the page). The page is just blank!
> Debugging showed that my struts action scrollarticles.do or any other action 
> that is called is executed correctly, but no response is rendered to the 
> client browser (there is no HTML source that the browser could display, it's 
> not just an error in the HTML output).
> Also I get the blank page more often on IE6 than on Opera 7, but both 
> browsers 
> are configured to load a page upon every single request (not loading from 
> local cache).
> Is this a bug or am I totally wrong on the use of h:outputLink???
> I know that s:form logically submits to a struts action, but the rendered 
> HTML 
> submits to layout.faces because I'm using Tiles. Is it just wrong call a .do 
> directly???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2161) DynaActionForm.toString() crashes for Integer-keyed Maps

 [ http://issues.apache.org/struts/browse/STR-2161?page=all ]
 
David Evans reopened STR-2161:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> DynaActionForm.toString() crashes for Integer-keyed Maps
> 
>
>  Key: STR-2161
>  URL: http://issues.apache.org/struts/browse/STR-2161
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.1 RC2
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Tim
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> When a DynaActionForm has a property which is a Map that uses Integers as its 
> keys, the toString() method throws a ClassCastException at line 552.
> My revision of DynaActionForm.java is 1.8.  The line that throws the 
> exception 
> is "String key = (String) keys.next();" but an Integer cannot be cast to a 
> String (I assume several others also cannot be cast to String).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2161) DynaActionForm.toString() crashes for Integer-keyed Maps

 [ http://issues.apache.org/struts/browse/STR-2161?page=all ]
 
David Evans closed STR-2161:


Resolution: Fixed

> DynaActionForm.toString() crashes for Integer-keyed Maps
> 
>
>  Key: STR-2161
>  URL: http://issues.apache.org/struts/browse/STR-2161
>  Project: Struts Action 1
> Type: Bug

>   Components: Action
> Versions: 1.1 RC2
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Tim
> Assignee: David Evans
>  Fix For: 1.2 Family

>
> When a DynaActionForm has a property which is a Map that uses Integers as its 
> keys, the toString() method throws a ClassCastException at line 552.
> My revision of DynaActionForm.java is 1.8.  The line that throws the 
> exception 
> is "String key = (String) keys.next();" but an Integer cannot be cast to a 
> String (I assume several others also cannot be cast to String).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2142) Replacement of LookupDispatchAction

 [ http://issues.apache.org/struts/browse/STR-2142?page=all ]
 
David Evans reopened STR-2142:
--

Assign To: David Evans  (was: Struts Developer Mailing List)

> Replacement of LookupDispatchAction
> ---
>
>  Key: STR-2142
>  URL: http://issues.apache.org/struts/browse/STR-2142
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.1 Final
>  Environment: Operating System: All
> Platform: All
> Reporter: Jean-Baptiste Nizet
> Assignee: David Evans
> Priority: Minor
>  Attachments: ParameterDispatchAction.java, ParameterDispatchAction.java, 
> SelectAction.java, SelectAction.java, SelectAction.java, SelectAction.java, 
> SelectAction.java, SelectAction.java, SelectAction.java, 
> strings_properties_patchfile.txt
>
> LookupDispatchAction is useful as a DispatchAction when you have multiple
> buttons on the same form. However, I think another powerful way to solve this
> problem could be used: select a method from a list defined in the mapping
> parameter attribute by checking the presence of o request parameter name.
> See the following cut'n pasted javadoc for details, and see the following
> attachment for an implementation.
> /**
>  * This class has the same goal as the DispatchAction: select the appropriate
>  * method to execute based on a request parameter. The way to determine which 
>  * method to call works in a different way, though. The parameter attribute 
> of 
>  * the mapping contains a list of method names. If one of the request 
> parameters
>  * has the same name as one of the method names specified in the list of 
> method
>  * names, this method is executed. If none of the request parameters has one
>  * of the method names, the unspecified method is invoked. 
>  * This class has the same goal and utility as the LookupDispatchAction: it 
>  * allows having several submit buttons on the same form. All that is needed 
> with
>  * this class is to give each button a different name (example: preview/post).
>  * It's more powerful than the LookupDispatchAction for several reasons, 
> though:
>  * 
>  *   The submit buttons don't need to be declared in the various 
>  *   internationalized ApplicationResources.properties files (useful if 
> JSTL
>  *   tags are preferred to the Struts tags)
>  *   It's more performant
>  *   Two submit buttons may have the same text
>  *   Links can easily use this kind of action as well as buttons
>  *   (ex: doThis.do?preview=&subject=...)
>  *   Hidden fields may easily be used to select the method 
>  *   (ex:  )
>  *   There is no need for the developer to override any abstract 
> method
>  * 
>  * @author Jean-Baptiste Nizet
>  */

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (STR-2142) Replacement of LookupDispatchAction

 [ http://issues.apache.org/struts/browse/STR-2142?page=all ]
 
David Evans closed STR-2142:


Resolution: Fixed

> Replacement of LookupDispatchAction
> ---
>
>  Key: STR-2142
>  URL: http://issues.apache.org/struts/browse/STR-2142
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.1 Final
>  Environment: Operating System: All
> Platform: All
> Reporter: Jean-Baptiste Nizet
> Assignee: David Evans
> Priority: Minor
>  Attachments: ParameterDispatchAction.java, ParameterDispatchAction.java, 
> SelectAction.java, SelectAction.java, SelectAction.java, SelectAction.java, 
> SelectAction.java, SelectAction.java, SelectAction.java, 
> strings_properties_patchfile.txt
>
> LookupDispatchAction is useful as a DispatchAction when you have multiple
> buttons on the same form. However, I think another powerful way to solve this
> problem could be used: select a method from a list defined in the mapping
> parameter attribute by checking the presence of o request parameter name.
> See the following cut'n pasted javadoc for details, and see the following
> attachment for an implementation.
> /**
>  * This class has the same goal as the DispatchAction: select the appropriate
>  * method to execute based on a request parameter. The way to determine which 
>  * method to call works in a different way, though. The parameter attribute 
> of 
>  * the mapping contains a list of method names. If one of the request 
> parameters
>  * has the same name as one of the method names specified in the list of 
> method
>  * names, this method is executed. If none of the request parameters has one
>  * of the method names, the unspecified method is invoked. 
>  * This class has the same goal and utility as the LookupDispatchAction: it 
>  * allows having several submit buttons on the same form. All that is needed 
> with
>  * this class is to give each button a different name (example: preview/post).
>  * It's more powerful than the LookupDispatchAction for several reasons, 
> though:
>  * 
>  *   The submit buttons don't need to be declared in the various 
>  *   internationalized ApplicationResources.properties files (useful if 
> JSTL
>  *   tags are preferred to the Struts tags)
>  *   It's more performant
>  *   Two submit buttons may have the same text
>  *   Links can easily use this kind of action as well as buttons
>  *   (ex: doThis.do?preview=&subject=...)
>  *   Hidden fields may easily be used to select the method 
>  *   (ex:  )
>  *   There is no need for the developer to override any abstract 
> method
>  * 
>  * @author Jean-Baptiste Nizet
>  */

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (STR-2091) EmptyTag does not worth with Arrays