svn commit: r397775 - /incubator/webwork2/STATUS.txt
Author: mrdon Date: Thu Apr 27 23:00:59 2006 New Revision: 397775 URL: http://svn.apache.org/viewcvs?rev=397775view=rev Log: Updated status with Java 5 vote results, added ePlus copyright task Modified: incubator/webwork2/STATUS.txt Modified: incubator/webwork2/STATUS.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=397775r1=397774r2=397775view=diff == --- incubator/webwork2/STATUS.txt (original) +++ incubator/webwork2/STATUS.txt Thu Apr 27 23:00:59 2006 @@ -61,11 +61,17 @@ DISTRIBUTION RIGHTS - LICENSING -optiontransferselect.js -* Don has contacted Matt Kruse about relicensing or filing a code grant +action/src/main/java/org/apache/struts/action2/spring/interceptor/SessionContextAutowiringInterceptor.java +* Jason needs to remove the ePlus copyright, mistakenly added by his IDE +VOTE TO TARGET JAVA 5 + ++1: 13, +0: 3, -0: 1 ... so the vote passed +http://www.mail-archive.com/dev%40struts.apache.org/msg20732.html + + MIGRATING FROM ACTION 1 TO ACTION 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r397781 - in /struts/action/trunk/integration: ./ apps-it/ apps-it/src/ apps-it/src/test/ apps-it/src/test/java/ apps-it/src/test/java/org/ apps-it/src/test/java/org/apache/ apps-it/src/te
Author: wsmoak
Date: Thu Apr 27 23:27:27 2006
New Revision: 397781
URL: http://svn.apache.org/viewcvs?rev=397781view=rev
Log:
Added automated tests to confirm that each example app starts and displays its
default page.
Use 'mvn -P perform-itest' to run the tests.
Issue: STR-2850
Added:
struts/action/trunk/integration/apps-it/
struts/action/trunk/integration/apps-it/pom.xml (with props)
struts/action/trunk/integration/apps-it/src/
struts/action/trunk/integration/apps-it/src/test/
struts/action/trunk/integration/apps-it/src/test/java/
struts/action/trunk/integration/apps-it/src/test/java/org/
struts/action/trunk/integration/apps-it/src/test/java/org/apache/
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/AppsTest.java
(with props)
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java
(with props)
Modified:
struts/action/trunk/integration/pom.xml
Added: struts/action/trunk/integration/apps-it/pom.xml
URL:
http://svn.apache.org/viewcvs/struts/action/trunk/integration/apps-it/pom.xml?rev=397781view=auto
==
--- struts/action/trunk/integration/apps-it/pom.xml (added)
+++ struts/action/trunk/integration/apps-it/pom.xml Thu Apr 27 23:27:27 2006
@@ -0,0 +1,121 @@
+?xml version=1.0?
+!--
+/*
+ * Copyright 2005-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * $Id$
+ */
+--
+
+project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
+
+ parent
+ groupIdorg.apache.struts.action/groupId
+ artifactIdstruts-action-it/artifactId
+ version1.3.3-SNAPSHOT/version
+ /parent
+
+ modelVersion4.0.0/modelVersion
+ groupIdorg.apache.struts.action/groupId
+ artifactIdstruts-action-it-apps/artifactId
+ packagingpom/packaging
+ nameStruts Action - Integration - Apps Tests/name
+ urlhttp://struts.apache.org/url
+
+ dependencies
+ dependency
+ groupIdjunit/groupId
+ artifactIdjunit/artifactId
+ version3.8.1/version
+ /dependency
+ dependency
+ groupIdhtmlunit/groupId
+ artifactIdhtmlunit/artifactId
+ version1.8/version
+ exclusions
+exclusion
+ groupIdjavax.xml/groupId
+ artifactIdjsr173/artifactId
+/exclusion
+ /exclusions
+ /dependency
+ dependency
+ groupIdorg.codehaus.cargo/groupId
+ artifactIdcargo-core-uberjar/artifactId
+ version0.8/version
+ scopetest/scope
+ /dependency
+ dependency
+ groupIdorg.codehaus.cargo/groupId
+ artifactIdcargo-ant/artifactId
+ version0.8/version
+ scopetest/scope
+ /dependency
+ /dependencies
+
+ profiles
+ profile
+ idperform-itest/id
+ build
+plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-compiler-plugin/artifactId
+ executions
+ execution
+idcompiler-for-tests/id
+phasetest-compile/phase
+goals
+ goaltestCompile/goal
+/goals
+ /execution
+ /executions
+ /plugin
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-surefire-plugin/artifactId
+ configuration
+ systemProperties
+property
+ namecargo.tomcat5x.home/name
+ value${cargo.tomcat5x.home}/value
+/property
+property
+ namecargo.servlet.port/name
+ value8080/value
+/property
+property
+ nameversion/name
+ value${version}/value
+
[jira] Assigned: (WW-1281) Allow StreamResult parameters to be read from the stack
[ http://issues.apache.org/struts/browse/WW-1281?page=all ] Rene Gielen reassigned WW-1281: --- Assign To: Rene Gielen Allow StreamResult parameters to be read from the stack --- Key: WW-1281 URL: http://issues.apache.org/struts/browse/WW-1281 Project: Struts Action 2 Type: Improvement Components: Views, Configuration, Dispatch Versions: WW 2.2.2 Environment: Any Reporter: Eric Molitor Assignee: Rene Gielen Fix For: 2.0 Attachments: StreamResult.patch This patch allows the parameters for the stream result to be read from the stack. I seem to be having issues running the unit tests so none are included. (I'll probably work on some later). Precedence is given to values on the stack over values in the XML file. I plan to use the patch as follows In xwork.xml I create a global stream result.. result name=stream type=stream / Then in my actions I create getter methods for the various parameters (probably just contentDisposition, contentType, and contentLength) and then just return stream as the result of my execute method. -- 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: r397784 - in /struts/action/trunk/integration/apps-it: pom.xml src/test/java/org/apache/struts/apps/AppsTest.java src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java
Author: wsmoak
Date: Thu Apr 27 23:31:16 2006
New Revision: 397784
URL: http://svn.apache.org/viewcvs?rev=397784view=rev
Log:
Removed svn:executable property
Modified:
struts/action/trunk/integration/apps-it/pom.xml (props changed)
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/AppsTest.java
(props changed)
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java
(props changed)
Propchange: struts/action/trunk/integration/apps-it/pom.xml
('svn:executable' removed)
Propchange:
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/AppsTest.java
('svn:executable' removed)
Propchange:
struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java
('svn:executable' removed)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WW-888) Clean up tutorials
[ http://issues.apache.org/struts/browse/WW-888?page=comments#action_37239 ] Rene Gielen commented on WW-888: Victor, are you still working on this one? Things have changes a bit, we have new options now like thinking of using the mailreader now ported to WW/SAF2 and such... although I think porting the WWIA examples to SAF2 should be done as well. Patrick, Jason? Clean up tutorials -- Key: WW-888 URL: http://issues.apache.org/struts/browse/WW-888 Project: Struts Action 2 Type: Task Components: Documentation Reporter: Patrick Lightbody Fix For: 2.0 http://wiki.opensymphony.com/display/WW/Tutorial -- 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-2850) Add tests to confirm that example apps work
[ http://issues.apache.org/struts/browse/STR-2850?page=all ] Wendy Smoak resolved STR-2850: -- Fix Version: 1.3.3 Resolution: Fixed Add tests to confirm that example apps work --- Key: STR-2850 URL: http://issues.apache.org/struts/browse/STR-2850 Project: Struts Action 1 Type: Improvement Components: Apps Versions: Nightly Build Reporter: Wendy Smoak Assignee: Wendy Smoak Priority: Minor Fix For: 1.3.3 Simple automated tests using HtmlUnit and Cargo, to confirm that each example app deploys, starts, and displays its default page. -- 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] Commented: (WW-1295) Datepicker doesn't work with swedish locale (with workarounds)
[ http://issues.apache.org/struts/browse/WW-1295?page=comments#action_37240 ] Rene Gielen commented on WW-1295: - Hmm, since jscalendar was kicked out, this issue is hard to solve :) I have not checked yet, but do we already have an action2-extens project at OS where the extensions with licensing issues should be located? As for jscalendar, we had quite heavy improvements beside the integration stuff, so we might want to give them a new home. 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 Assignee: Rainer Hermanns Fix For: 2.0 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: ww:datepicker name=aNiceSwedishNameLikeMeatBalls label=aNiceSwedishLabelLikeSmorgasbord language=sv/ -- 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] Created: (STR-2851) The Struts Tiles jar is missing from the 1.3.2 distribution
The Struts Tiles jar is missing from the 1.3.2 distribution --- Key: STR-2851 URL: http://issues.apache.org/struts/browse/STR-2851 Project: Struts Action 1 Type: Bug Versions: 1.3.2 Reporter: Wendy Smoak Assigned to: Wendy Smoak Fix For: 1.3.3 Reported by Jürgen Zimmermann 1.3.2: JAR file for tiles is missing in the distribution There is no jar file for tiles in the lib subdirectory. -- 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-2851) The Struts Tiles jar is missing from the 1.3.2 distribution
[ http://issues.apache.org/struts/browse/STR-2851?page=all ] Wendy Smoak resolved STR-2851: -- Resolution: Fixed http://svn.apache.org/viewcvs?rev=397772view=rev The Struts Tiles jar is missing from the 1.3.2 distribution --- Key: STR-2851 URL: http://issues.apache.org/struts/browse/STR-2851 Project: Struts Action 1 Type: Bug Versions: 1.3.2 Reporter: Wendy Smoak Assignee: Wendy Smoak Fix For: 1.3.3 Reported by Jürgen Zimmermann 1.3.2: JAR file for tiles is missing in the distribution There is no jar file for tiles in the lib subdirectory. -- 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]
[ANN] JSPTabControl taglib (was Re: Bearing down on Struts Action 1.3.2)
Thanks for mentioning this project, Angelo. In the future, you can start a new thread for product announcements. It's also helpful to include [ANN] or [ANNOUNCE]' in the subject line. When you are ready for a stable release, the user@struts.apache.org list is usually the best place to announce extensions and taglibs. -Ted. On 4/27/06, Angelo zerr [EMAIL PROTECTED] wrote: Hello; I mail you to announce JSPTabControl project is created. JSPTabControl is JSP taglib for manage tabs in your JSP. This taglib generate tabs with pure CSS tabs technique (using li and ul). JSPtabControl give you several features : 1. tab control (body and header) and tab page (body and header) can be easily customized with CSS. 2. titles of tab header page can be localized, by using Struts AplicationResources or Resource Bundle file properties. 3. select a tab with JAVA code (for example in your action struts). 4. keep last tab selected after posting form. 5. set a state (INVISIBLE, READ-ONLY, FORBIDDEN, ERROR, ...) with JAVA code for a particulary tab page : 5.1. to manage render of tab page (header and body) by using CSS. 5.2. to execute function javascript swith events (eg : when tab page has FORBIDDEN state, you could execute javascrit message alert You are not authorized to access this tab! when user click in this tab page). You can manage any states. States are configurate (Style class and Javascript to execute) into XML file. States can be used for exemple to manage role in your WEB Application. 6. use EL syntax (see JSTL specification) in JSPTabControl attributes taglib (with, height,...) to evaluate JSP expressions dynamically. You can find JSPTabControl WEB site at http://jsptabcontrol.sourceforge.net/ and download it at http://sourceforge.net/project/showfiles.php?group_id=161371 Regards Angelo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.2: JAR file for tiles is missing in the distribution
That should have been resolved with what I did last night. Can you verify? -- James Mitchell On Apr 28, 2006, at 1:46 AM, Wendy Smoak wrote: On 4/27/06, Jürgen Zimmermann [EMAIL PROTECTED] wrote: There is no jar file for tiles in the lib subdirectory. Thanks for reporting this! I'll fix the build files, meanwhile you can grab the Tiles jar here: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ action/struts-tiles/1.3.2/ -- 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]
[Struts Wiki] Trivial Update of RoughSpots by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates + [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.2: JAR file for tiles is missing in the distribution
Never mind, I wasn't thinking assembly, I was thinking pom(head smack). Sorry for the noise. -- James Mitchell On Apr 28, 2006, at 6:59 AM, James Mitchell wrote: That should have been resolved with what I did last night. Can you verify? -- James Mitchell On Apr 28, 2006, at 1:46 AM, Wendy Smoak wrote: On 4/27/06, Jürgen Zimmermann [EMAIL PROTECTED] wrote: There is no jar file for tiles in the lib subdirectory. Thanks for reporting this! I'll fix the build files, meanwhile you can grab the Tiles jar here: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ action/struts-tiles/1.3.2/ -- 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]
[Struts Wiki] Update of StrutsMavenRelease by JamesMitchell
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by JamesMitchell:
http://wiki.apache.org/struts/StrutsMavenRelease
The comment on the change is:
Add item for testing the apps with Wendy's new super-cool-webapp-tester-thingee
--
1. Create the new directory on cvs.apache.org, for example
cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x')
1. Ensure that your settings.xml contains a server for
apache-maven-test-builds (see the Suggested Settings section on
StrutsMaintenanceMaven)
1. Clear out your local Maven repo
- 1. Build all jar and war artifacts, including -sources and -javadoc, and
deploy them to maven-snapshot-repository.
+ 1. Build all jar and war artifacts, including -sources and -javadoc,
+ 11. verifiy war files
+ 111. cd to {your struts checkout}/action/integration/apps-it
+ 111. run $mvn -P perform-itest
+ 11. deploy them to maven-snapshot-repository.
1. Build and deploy the website
1. Create the assembly and upload it to cvs.apache.org/dist
1. Make sure that everything under
maven-snapshot-repository/org/apache/struts is group writeable
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.2 Quality
Should we move the ToDo items from the bottom of StrutsMavenMaintenance wiki page to subtasks of a JIRA ticket? If so, we could also add the tasks you mentioned below. I'd like to help, but I'm not 100% sure about what all we want done, in what order, and by whom. Having things spread out between the wiki, jira, and the mailing list only seems to compound the problem. I am encouraged though, as activity has really picked up lately. Let's keep this ball rolling! -- James Mitchell On Apr 28, 2006, at 7:24 AM, Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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: r397878 - /struts/pom/
Author: jmitchell Date: Fri Apr 28 05:21:44 2006 New Revision: 397878 URL: http://svn.apache.org/viewcvs?rev=397878view=rev Log: ignore local eclipse stuff Modified: struts/pom/ (props changed) Propchange: struts/pom/ -- --- svn:ignore (added) +++ svn:ignore Fri Apr 28 05:21:44 2006 @@ -0,0 +1,4 @@ +.classpath +.project +bin + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WW-1303) Form Tag needs accept-charset attribute
Form Tag needs accept-charset attribute --- Key: WW-1303 URL: http://issues.apache.org/struts/browse/WW-1303 Project: Struts Action 2 Type: Bug Components: Views Versions: WW 2.1.8, WW 2.2.1, WW 2.2.2 Reporter: Rainer Hermanns Assigned to: Rainer Hermanns Fix For: 2.0 When trying to use the form tag with UTF-8 encoded input and method=POST the textual contents are not rendered with the proper encoding. -- 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]
[Struts Wiki] Update of RoughSpots by plightbo
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by plightbo: http://wiki.apache.org/struts/RoughSpots -- [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is - [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [plightbo] Agreed - examples, default results, etc should be JSP. However, we need to keep UI tags in a template language so they can be used in all view technologies. Right now that is FreeMarker, though if we can find a template language that is more like JSP (say, without the scripplets), I would like to switch to that. 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we use it extensively. It's the best validation framework I've seen out there, and NO, validate methods are NOT enough. For instance, we define reusable validations for our domain models and use them for both the web front end as well as web services and batch imports. * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. - * [rainerh] -1 on removing the valdation framework. This is one of the best, if not the best validation framework I've seen so far. + * [rainerh] -1 on removing the validation framework. This is one of the best, if not the best validation framework I've seen so far. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [jcarreira] You're kidding, right? We've discussed this already @@ -243, +244 @@ * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + * [plightbo] The reference docs are great, but we failed terribly on the
RoughSpots ramp down
I propose that everyone get their last two cents in to the RoughSpots document today so that we can ramp down the discussions and then pick apart each issue, decide which we want/can attack right now, and come up with proposals. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28543messageID=55430#55430 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates - [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. + * [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. @@ -238, +238 @@ * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [phil] -1 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. @@ -274, +276 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's
[jira] Reopened: (STR-2850) Add tests to confirm that example apps work
[ http://issues.apache.org/struts/browse/STR-2850?page=all ] Wendy Smoak reopened STR-2850: -- The integration/apps-it module needs to be added to the assembly. Add tests to confirm that example apps work --- Key: STR-2850 URL: http://issues.apache.org/struts/browse/STR-2850 Project: Struts Action 1 Type: Improvement Components: Apps Versions: Nightly Build Reporter: Wendy Smoak Assignee: Wendy Smoak Priority: Minor Fix For: 1.3.3 Simple automated tests using HtmlUnit and Cargo, to confirm that each example app deploys, starts, and displays its default page. -- 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: [VOTE] Struts Action Framework v1.3.2 Quality
I went through every open bug ticket last night, and out of them all, there only a handful outstanding, and none that are serious; again, why I think this is a beta release. Perhaps we need a better definition of quality, because to me, beta means there are some minor issues, but the code works, the examples work, and you could start using it in a development environment without problems. Don Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.2 Quality
James Mitchell wrote: Should we move the ToDo items from the bottom of StrutsMavenMaintenance wiki page to subtasks of a JIRA ticket? Absolutely! We have an infrastructure component in the Action 1 project just for these types of issues. JIRA helps by collecting what needs to be done, any comments on it, and who is working on it. WebWork used it a lot to even when the solution is being actively developed, which I think is a great idea for those longer tasks. Don If so, we could also add the tasks you mentioned below. I'd like to help, but I'm not 100% sure about what all we want done, in what order, and by whom. Having things spread out between the wiki, jira, and the mailing list only seems to compound the problem. I am encouraged though, as activity has really picked up lately. Let's keep this ball rolling! -- James Mitchell On Apr 28, 2006, at 7:24 AM, Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. + + /!\ '''Edit conflict - other version:''' * [phil] -1 + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + + /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + + /!\ '''Edit conflict - your version:''' + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. + + /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -276, +291 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + + /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -297, +318 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here:
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. - - /!\ '''Edit conflict - other version:''' * [phil] -1 - - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 - - /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). - - /!\ '''Edit conflict - your version:''' - * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. - /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -291, +279 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) - - /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -318, +301 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https://issues.apache.org/struts/browse/WW-1133]. * [plightbo] I still don't
Re: [VOTE] Struts Action Framework v1.3.2 Quality
On 4/28/06, Don Brown [EMAIL PROTECTED] wrote: I went through every open bug ticket last night, and out of them all, there only a handful outstanding, and none that are serious; again, why I think this is a beta release. I added a Struts Action 1 filter to list all the open bugs against SAF1, which comes up with thirty issues. I agree that not all of these need to be handled by the 1.3.2 release plan, but it would be help to itemize the open tickets, so that we know what is not being handled and why. Perhaps we need a better definition of quality, because to me, beta means there are some minor issues, but the code works, the examples work, and you could start using it in a development environment without problems. To me, a Beta means that if it works for more people, we could upgrade it to GA. The JIRA issues aside, I could never vote this release to GA since some of the documentation is already obsolete. But, that's OK. I'm not the only one with a vote, and no one can veto a release :) Don Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SB-1) [scaffold] BaseAction.executeLogic() calls removed ActionServlet.log(String, Integer)
[ http://issues.apache.org/struts/browse/SB-1?page=all ] Don Brown moved STR-2305 to SB-1: - Project: Sandbox (was: Struts Action 1) Key: SB-1 (was: STR-2305) Component: (was: Sandbox) Version: (was: 1.2.4) [scaffold] BaseAction.executeLogic() calls removed ActionServlet.log(String, Integer) - Key: SB-1 URL: http://issues.apache.org/struts/browse/SB-1 Project: Sandbox Type: Bug Environment: Operating System: All Platform: All Reporter: J. Patterson Waltz III Assignee: Ted Husted The struts.scaffold.RelayAction (and perhaps other scaffold actions), does not overload the executeLogic method of the BaseAction, and this method throws a java.lang.NoSuchMethodError when used with Struts 1.2.4, as the ActionServlet.log(String, Integer) method which it calls was first deprecated and then removed. The BaseAction should have this logging statement removed, or updated to the currently preferred commons-logging format. -- 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] Moved: (SB-3) processLocale creates session no matter if it doesn't exist
[ http://issues.apache.org/struts/browse/SB-3?page=all ]
Don Brown moved STR-2545 to SB-3:
-
Project: Sandbox (was: Struts Action 1)
Key: SB-3 (was: STR-2545)
Component: (was: Sandbox)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
processLocale creates session no matter if it doesn't exist
---
Key: SB-3
URL: http://issues.apache.org/struts/browse/SB-3
Project: Sandbox
Type: Bug
Environment: Operating System: other
Platform: All
Reporter: Johnny Patino
Index: RequestProcessor.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java,v
retrieving revision 1.45
diff -u -r1.45 RequestProcessor.java
--- RequestProcessor.java 25 Apr 2004 02:29:41 - 1.45
+++ RequestProcessor.java 10 Aug 2005 17:49:41 -
@@ -599,7 +599,9 @@
}
// Has a Locale already been selected?
-HttpSession session = request.getSession();
+HttpSession session = request.getSession(false);
+if (session == null)
+ return;
if (session.getAttribute(Globals.LOCALE_KEY) != null) {
return;
}
--
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] Moved: (SB-5) [scaffold] BaseAction.getMessageResources calls removed ActionServlet.getResources()
[ http://issues.apache.org/struts/browse/SB-5?page=all ] Don Brown moved STR-2308 to SB-5: - Project: Sandbox (was: Struts Action 1) Key: SB-5 (was: STR-2308) Component: (was: Sandbox) Version: (was: 1.2.4) [scaffold] BaseAction.getMessageResources calls removed ActionServlet.getResources() Key: SB-5 URL: http://issues.apache.org/struts/browse/SB-5 Project: Sandbox Type: Bug Environment: Operating System: All Platform: All Reporter: J. Patterson Waltz III Assignee: Ted Husted Attachments: scaffold-1.2.4-patch.txt The struts-scaffold BaseAction.getMessageResources() method throws a NoSuchMethodError as it tries to call the now inexistent ActionServlet.getResources() method. This invocation should be changed to Action.getResources(HttpServletRequest). -- 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] Moved: (SB-2) [ti] Ti/JSF sample
[ http://issues.apache.org/struts/browse/SB-2?page=all ] Don Brown moved STR-2570 to SB-2: - Project: Sandbox (was: Struts Action 1) Key: SB-2 (was: STR-2570) Component: (was: Sandbox) Version: (was: Nightly Build) [ti] Ti/JSF sample -- Key: SB-2 URL: http://issues.apache.org/struts/browse/SB-2 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Rich Feit Assignee: Don Brown Attachments: wars_samples-jsf_patch.txt This is a sample that demonstrates using JSF as the view tier for Ti. To run this: - 'maven jar jar:install' in jars/core and jars/java5 - 'maven war' in wars/samples-jsf - deploy the file wars/samples-jsf/target/struts-ti-jsf.war -- 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] Moved: (SB-4) [ti] phase2: annotation reduction
[ http://issues.apache.org/struts/browse/SB-4?page=all ] Don Brown moved STR-2690 to SB-4: - Project: Sandbox (was: Struts Action 1) Key: SB-4 (was: STR-2690) Component: (was: Sandbox) Version: (was: Nightly Build) [ti] phase2: annotation reduction - Key: SB-4 URL: http://issues.apache.org/struts/browse/SB-4 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Rich Feit Assignee: Don Brown Attachments: patch-kill-annotations.txt This patch does a few things to reduce the number/size of annotations in the phase2 directory. It's mainly just a POC. - Each controller can specify its own default result suffix, like _success.faces. This means that most of the @ti.action/@ti.forward annotations in the JSF sample go away. - If an action has a single forward, you can now put the @ti.forward directly on the action method, rather than nesting it in a @ti.action. - You no longer need to specify @ti.action at all if there's no additional configuration; all String- and Forward-returning methods with zero or one arguments become actions. patch -p0 patch-kill-annotations.txt svn add phase2/jars/core/src/java/org/apache/ti/compiler/internal/SynthesizedAnnotation.java svn add phase2/wars/samples-jsf/src/java/jsf/begin_success.java svn add phase2/wars/samples-jsf/src/java/jsf/physiciansFlow/begin_success.java svn add phase2/wars/samples-jsf/src/java/jsf/physiciansFlow/physicianDetail_success.java svn add phase2/wars/samples-jsf/src/webapp/jsf/begin_success.jsp svn add phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/begin_success.jsp svn add phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/displayPhysiciansWithDetail_success.jsp svn add phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/physicianDetail_success.jsp svn add phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/submitMailMessage_success.jsp svn delete --force phase2/wars/samples-jsf/src/java/jsf/home.java svn delete --force phase2/wars/samples-jsf/src/java/jsf/physiciansFlow/physicianDetail.java svn delete --force phase2/wars/samples-jsf/src/java/jsf/physiciansFlow/physicianResultsWithDetail.java svn delete --force phase2/wars/samples-jsf/src/java/jsf/physiciansFlow/search.java svn delete --force phase2/wars/samples-jsf/src/webapp/jsf/home.jsp svn delete --force phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/confirmMailSent.jsp svn delete --force phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/physicianDetail.jsp svn delete --force phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/physicianResultsWithDetail.jsp svn delete --force phase2/wars/samples-jsf/src/webapp/jsf/physiciansFlow/search.jsp -- 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] Moved: (SB-6) [ti] Fix Ti to build/run on JDK 1.4, and remove XMLBeans dependence
[ http://issues.apache.org/struts/browse/SB-6?page=all ] Don Brown moved STR-2592 to SB-6: - Project: Sandbox (was: Struts Action 1) Key: SB-6 (was: STR-2592) Component: (was: Sandbox) Version: (was: Nightly Build) [ti] Fix Ti to build/run on JDK 1.4, and remove XMLBeans dependence --- Key: SB-6 URL: http://issues.apache.org/struts/browse/SB-6 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Rich Feit Assignee: Don Brown Attachments: ti-java14-and-xml.patch Here's a patch that: - Fixes the build/samples to run under JDK 1.4 wherever possible. - Removes the internal dependence on XMLBeans and XMLBeans-generated schema classes. - Fixes up some of the naming in XML filenames/elements/schema namespaces (netui - ti). Patch instructions (from the root of the Ti tree): svn up -r 290666 patch -p0 ti-java14-and-xml.patch svn add jars/core/src/java/org/apache/ti/pageflow/internal/annotationreader svn add jars/core/src/java/org/apache/ti/core/urltemplates/schema svn add jars/core/src/java/org/apache/ti/compiler/internal/LocalFileEntityResolver.java svn add jars/core/src/java/org/apache/ti/compiler/internal/resources svn add jars/core/src/java/org/apache/ti/compiler/internal/model/XmlElementSupport.java svn add jars/core/src/java/org/apache/ti/util/xml svn add jars/core/src/java/org/apache/ti/util/config/schema svn add jars/core/src/java/org/apache/ti/util/config/bean svn add jars/core/src/java/org/apache/ti/util/config/internal svn add jars/core/src/java/org/apache/ti/util/config/parser svn delete --force jars/core/src/java/org/apache/ti/compiler/internal/model/validation/ValidatableFieldFactory.java svn delete --force jars/core/src/java/org/apache/ti/compiler/internal/model/validation/ValidatableFieldOld.java svn delete --force jars/core/src/java/org/apache/ti/util/config/struts-ti-config-default.xmlgrep I tried it against a fresh sync -- seems to work, but let me know if you run into any issues. Only one note for public consumption, after this is committed: You can now build/run under JDK 1.4: cd jars/core maven jar jar:install cd ../compiler-xdoclet maven jar jar:install cd ../../wars/samples-xdoclet maven war Then, deploy wars/samples-xdoclet/target/struts-ti-xdoclet. -- 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] Moved: (SB-7) [ti] generation of XWork config files from annotations
[ http://issues.apache.org/struts/browse/SB-7?page=all ]
Don Brown moved STR-2577 to SB-7:
-
Project: Sandbox (was: Struts Action 1)
Key: SB-7 (was: STR-2577)
Component: (was: Sandbox)
Version: (was: Nightly Build)
[ti] generation of XWork config files from annotations
--
Key: SB-7
URL: http://issues.apache.org/struts/browse/SB-7
Project: Sandbox
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: Rich Feit
Assignee: Don Brown
Attachments: patch-xwork-annotations-gen.zip,
patch-xwork-gen-apt-and-xdoclet.zip
This patch adds in annotation (apt)-based generation of XWork config files.
Because there are file moves/deletes in it, you need to do the following to
apply the patch:
cd ${ti.root}
patch -p0 patch-xwork-annotations-gen.txt
svn delete --force wars/samples/src/java/pageflow
svn delete --force
wars/samples/src/java/org/apache/ti/samples/pageflow/loginexample/BaseFlow.java
svn delete --force wars/samples/src/resources/_pageflow-config
svn delete --force
wars/samples-jsf/src/java/jsf/physiciansFlow/Controller.java
svn delete --force
wars/samples-jsf/src/java/jsf/physiciansFlow/search.java
svn delete --force
wars/samples-jsf/src/java/jsf/physiciansFlow/physicianResultsWithDetail.java
svn delete --force
wars/samples-jsf/src/java/jsf/physiciansFlow/physicianDetail.java
svn delete --force wars/samples-jsf/src/java/jsf/Controller.java
svn delete --force wars/samples-jsf/src/java/jsf/home.java
svn delete --force
wars/samples-jsf/src/java/org/apache/beehive/samples/netui/jsf/SharedFlow.java
svn delete --force wars/samples-jsf/src/resources/_pageflow-config
I did try this out against a fresh sync, but if you have any problems let me
know.
After this patch is applied, the samples (and samples-jsf) are generated from
annotations in the source files. No more mockups!
--
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] Moved: (SB-8) [Standalone Tiles] Test fails due to URL problems on different platforms.
[ http://issues.apache.org/struts/browse/SB-8?page=all ] Don Brown moved STR-2557 to SB-8: - Project: Sandbox (was: Struts Action 1) Key: SB-8 (was: STR-2557) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles] Test fails due to URL problems on different platforms. - Key: SB-8 URL: http://issues.apache.org/struts/browse/SB-8 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Greg Reddin Attachments: patchfile.txt The TestReloadableDefinitionsFactory test fails on Windows because of the way the Windows JDK creates URLs. If you create an URL with the path E:/somedir/somefile then call url.toExternalForm() you will get file:E:/somedir/somefile. This is an invalid URL. It should be file:/E:/somedir/somefile. I've created a patch to fix this behavior. -- 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] Moved: (SB-9) [ti] re-patch for StrutsTiServlet.java
[ http://issues.apache.org/struts/browse/SB-9?page=all ] Don Brown moved STR-2561 to SB-9: - Project: Sandbox (was: Struts Action 1) Key: SB-9 (was: STR-2561) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [ti] re-patch for StrutsTiServlet.java -- Key: SB-9 URL: http://issues.apache.org/struts/browse/SB-9 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Rich Feit Attachments: bug36406-patch.txt I think my original patch might have been corrupt for StrutsTiServlet.java. I'm attaching an updated patch for just this file. It removes some initialization logic (-ServletInitialization.java) and some resource-resolving logic (everything uses ServletSourceResolver, either directly or indirectly). -- 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] Moved: (SB-14) [Standalone Tiles] Add Application Listener
[ http://issues.apache.org/struts/browse/SB-14?page=all ] Don Brown moved STR-2732 to SB-14: -- Project: Sandbox (was: Struts Action 1) Key: SB-14 (was: STR-2732) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles] Add Application Listener --- Key: SB-14 URL: http://issues.apache.org/struts/browse/SB-14 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: Other Reporter: Greg Reddin Priority: Minor Attachments: TilesListener.java Add an application listener that can replace TilesServlet in Servlet 2.3+ containers. It will contain the same functionality as TilesServlet. -- 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] Moved: (SB-11) Implement a more javascript feel for the ScriptableList
[ http://issues.apache.org/struts/browse/SB-11?page=all ]
Don Brown moved STR-2539 to SB-11:
--
Project: Sandbox (was: Struts Action 1)
Key: SB-11 (was: STR-2539)
Component: (was: Sandbox)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
Implement a more javascript feel for the ScriptableList
---
Key: SB-11
URL: http://issues.apache.org/struts/browse/SB-11
Project: Sandbox
Type: Bug
Environment: Operating System: other
Platform: All
Reporter: Ronald Villaver
Attachments: ScriptableList.java
This is to give the ScriptableList wrapper the more javascript feel in
reference
to manipulating data.
currently this wont work... because of IndexOutOfBounds exception when the
runtime tries to access a list with an index not yet there.
var a = new ArrayList();
a[5] = 1234;
Here's the suggested ScriptableList with modifications.
*
* Copyright 1999-2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.struts.flow.sugar;
import org.mozilla.javascript.*;
import java.util.*;
import java.io.Serializable;
/**
* Wrap a java.util.List for JavaScript.
*/
public class ScriptableList extends JavaObjectWrapper implements Scriptable,
Wrapper, Serializable {
private List list;
public ScriptableList() {
this.list = list;
}
public ScriptableList(List list) {
this.list = list;
this.javaObject = javaObject;
}
public ScriptableList(Scriptable scope, Object javaObject, Class
staticType,
Map funcs) {
super(scope, javaObject, staticType, funcs);
if (javaObject instanceof List) {
this.list = (List)javaObject;
} else {
throw new IllegalArgumentException(Passed object +javaObject+
is
not an instance of List);
}
}
public String getClassName() {
return staticType.toString();
}
public boolean has(int index, Scriptable start) {
//return (list.get(index) != null); -- this throws an
ArrayIndexOutOfBounds type error. You can just simply try catch this. This is
caused I think because the parser would try to retrieve the value
first(reading
the statement left to right) then assign the value to that index... or
something
like that.
try{
return (list.get(index) != null);
}catch(Exception e){
return false;
}
}
public Object get(int index, Scriptable start) {
return list.get(index);
}
public void put(int index, Scriptable start, Object value) {
//list.add(index, value);
// Another suggestion to have the full feel of javascript
array, is the
ability to set a variable at a higher index than the current length of the
array.
int max = index+1;
if(maxlist.size()){
for(int i=list.size();iindex;i++){
list.add(i,null);
}
list.add(index,value);
}else{
list.set(index,value);
}
}
public void delete(int index) {
list.remove(index);
}
public Object[] getIds() {
//TODO: optimize this :)
Integer[] ids = new Integer[list.size()];
for (int x=0; xids.length; x++) {
ids[x] = new Integer(x);
}
return ids;
}
public Object unwrap() {
return this.list;
}
}
--
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] Moved: (SB-10) [ti] expand StrutsFactory
[ http://issues.apache.org/struts/browse/SB-10?page=all ] Don Brown moved STR-2692 to SB-10: -- Project: Sandbox (was: Struts Action 1) Key: SB-10 (was: STR-2692) Component: (was: Sandbox) Version: (was: Nightly Build) [ti] expand StrutsFactory - Key: SB-10 URL: http://issues.apache.org/struts/browse/SB-10 Project: Sandbox Type: Bug Environment: Operating System: other Platform: Other Reporter: Rich Feit Assignee: Don Brown Attachments: patch-test-struts-factory.txt This is a first cut at some Struts 1.x wrappers (ModuleConfig, ActionMapping, ActionForward, ExceptionConfig) for XWork config objects (PackageConfig, ActionConfig, ResultConfig, ExceptionMappingConfig). Still needs to be filled out, but it's a start. Patch instructions: patch -p0 patch-test-struts-factory.txt svn add phase1/jars/legacy/src/java/org/apache/ti/legacy/WrapperActionForward.java svn add phase1/jars/legacy/src/java/org/apache/ti/legacy/WrapperActionMapping.java svn add phase1/jars/legacy/src/java/org/apache/ti/legacy/WrapperExceptionConfig.java svn add phase1/jars/legacy/src/java/org/apache/ti/legacy/WrapperModuleConfig.java svn add phase1/jars/legacy/src/test/org/apache/ti/legacy/test-struts-factory.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] Moved: (SB-13) [Standalone Tiles\ Remove Servlet API Dependencies
[ http://issues.apache.org/struts/browse/SB-13?page=all ] Don Brown moved STR-2730 to SB-13: -- Project: Sandbox (was: Struts Action 1) Key: SB-13 (was: STR-2730) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles\ Remove Servlet API Dependencies -- Key: SB-13 URL: http://issues.apache.org/struts/browse/SB-13 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: Other Reporter: Greg Reddin Priority: Minor Once the core library is ready we need to refine the API again to depend on a context class instead of Servlet classes. This will allow Tiles to be used within JSF and Portlet environments. Look at commons- chain and JSF for ideas. -- 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] Moved: (SB-15) [Standalone Tiles] Build Struts Integration
[ http://issues.apache.org/struts/browse/SB-15?page=all ] Don Brown moved STR-2731 to SB-15: -- Project: Sandbox (was: Struts Action 1) Key: SB-15 (was: STR-2731) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles] Build Struts Integration --- Key: SB-15 URL: http://issues.apache.org/struts/browse/SB-15 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: Other Reporter: Greg Reddin Priority: Minor Standalone Tiles has no Struts integration. Build the components needed to make Standalone Tiles work with Struts Action Framework. I'm not sure if Tiles or Struts Action is the best place to keep this. -- 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] Moved: (SB-12) [Standalone Tiles] Refactor DefinitionsFactory and Create Reloadable Definitions
[ http://issues.apache.org/struts/browse/SB-12?page=all ] Don Brown moved STR-2536 to SB-12: -- Project: Sandbox (was: Struts Action 1) Key: SB-12 (was: STR-2536) Component: (was: Sandbox) Version: (was: 1.3.0) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles] Refactor DefinitionsFactory and Create Reloadable Definitions Key: SB-12 URL: http://issues.apache.org/struts/browse/SB-12 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: Other Reporter: Greg Reddin Priority: Minor Attachments: patchfile.txt This is an enhancement request to refactor the Tiles DefinitionsFactory structure and provide support for reloadable Tiles definitions. It is applicable to the standalone Tiles project. The reason for the refactoring is as follows: The current structure for DefinitionsFactory is overly complicated and the desire is to simplify it and separate concerns. This refactoring externalizes the reading of data from config files and the structure of definitions objects from the ServletContext management. It also provides a servlet Filter to allow Tiles Definitions to be reloaded. Patch to be submitted shortly. -- 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] Moved: (SB-17) [Standalone Tiles] TilesServlet does not load all servlet parameters
[ http://issues.apache.org/struts/browse/SB-17?page=all ] Don Brown moved STR-2672 to SB-17: -- Project: Sandbox (was: Struts Action 1) Key: SB-17 (was: STR-2672) Component: (was: Sandbox) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) [Standalone Tiles] TilesServlet does not load all servlet parameters Key: SB-17 URL: http://issues.apache.org/struts/browse/SB-17 Project: Sandbox Type: Improvement Environment: Operating System: All Platform: PC Reporter: Antonio Petrelli Priority: Minor Attachments: tiles-patch-for-parameters.txt, tiles-patch-for-parameters.txt At startup, the TilesServlet class does not load and use all of init-param elements in web.xml. It uses only definitions-config parameters, the rest is ignored. -- 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] Moved: (SB-18) [Standalone Tiles] Refactor Taglib
[ http://issues.apache.org/struts/browse/SB-18?page=all ] Don Brown moved STR-2729 to SB-18: -- Project: Sandbox (was: Struts Action 1) Key: SB-18 (was: STR-2729) Component: (was: Sandbox) Version: (was: Nightly Build) [Standalone Tiles] Refactor Taglib -- Key: SB-18 URL: http://issues.apache.org/struts/browse/SB-18 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: Other Reporter: Greg Reddin Assignee: Greg Reddin Priority: Minor The API refactoring broke the taglib. It was patched back together enough to make it compile again, and so far it actually works. The core functionality needs to be extracted from the taglib and the codebase needs to be further refined to provide those features. In the process test cases need to be developed to verify the functionality. (How do you test a taglib?) -- 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] Moved: (SB-16) Changing the action dynamically without using javascript
[ http://issues.apache.org/struts/browse/SB-16?page=all ] Don Brown moved STR-2547 to SB-16: -- Project: Sandbox (was: Struts Action 1) Key: SB-16 (was: STR-2547) Component: (was: Sandbox) Version: (was: 1.2.7) Assign To: (was: Struts Developer Mailing List) Changing the action dynamically without using javascript Key: SB-16 URL: http://issues.apache.org/struts/browse/SB-16 Project: Sandbox Type: Improvement Environment: Operating System: other Platform: All Reporter: Nagaraj Priority: Minor Hi, I am facing the following problem in my application. First i will explain the problem context. My action class extending the DispatchAction.In my html: form tag will have default action.Say i have the buttons for Create, Read, Update,delate operations in my JSP.Now based on the button click , i wll change the action in the JavaScript.For example document.formName.action=/abc.do?method=read; Now the problem is we dont want to use javascript.but at the same we wants to use dispatchaction. So how do you will change the action dynamically without using the javascript? since button/image does not have action property. Can any one of you help me to solve this problem? Thank you Nagaraj P -- 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: r397918 - in /incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring: ./ interceptor/ lifecycle/
Author: jcarreira Date: Fri Apr 28 08:22:10 2006 New Revision: 397918 URL: http://svn.apache.org/viewcvs?rev=397918view=rev Log: Removing eplus copyright notice which was accidentally automatically added by an IDEA plugin and removing unused Spring integration classes Removed: incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/SessionContextSpringProxyableObjectFactory.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/interceptor/SessionContextAutowiringInterceptor.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/lifecycle/ApplicationContextSessionListener.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/lifecycle/SpringObjectFactoryListener.java Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/StrutsSpringObjectFactory.java Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/StrutsSpringObjectFactory.java URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/StrutsSpringObjectFactory.java?rev=397918r1=397917r2=397918view=diff == --- incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/StrutsSpringObjectFactory.java (original) +++ incubator/webwork2/action/src/main/java/org/apache/struts/action2/spring/StrutsSpringObjectFactory.java Fri Apr 28 08:22:10 2006 @@ -29,6 +29,8 @@ import javax.servlet.ServletContext; +import sun.rmi.runtime.Log; + /** * Struts object factory that integrates with Spring. * p/ @@ -55,7 +57,7 @@ log.fatal(message); return; } - + this.setApplicationContext(appContext); String autoWire = Configuration.getString(StrutsConstants.STRUTS_OBJECTFACTORY_SPRING_AUTOWIRE); @@ -70,7 +72,7 @@ type = AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR; } this.setAutowireStrategy(type); - + boolean useClassCache = true.equals(Configuration.getString(StrutsConstants.STRUTS_OBJECTFACTORY_SPRING_USE_CLASS_CACHE)); this.setUseClassCache(useClassCache); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.2 Quality
Ted Husted wrote: On 4/28/06, Don Brown [EMAIL PROTECTED] wrote: I went through every open bug ticket last night, and out of them all, there only a handful outstanding, and none that are serious; again, why I think this is a beta release. I added a Struts Action 1 filter to list all the open bugs against SAF1, which comes up with thirty issues. I agree that not all of these need to be handled by the 1.3.2 release plan, but it would be help to itemize the open tickets, so that we know what is not being handled and why. Perhaps we need a better definition of quality, because to me, beta means there are some minor issues, but the code works, the examples work, and you could start using it in a development environment without problems. To me, a Beta means that if it works for more people, we could upgrade it to GA. The JIRA issues aside, I could never vote this release to GA since some of the documentation is already obsolete. That makes sense, especially since we don't have an RC quality option. I wonder if we should add it, because there should be a way to indicate the code is pretty complete, stable, and free of major bugs, but at the same time, it isn't GA and is missing key ingredients like documentation and minor bug fixings. Don But, that's OK. I'm not the only one with a vote, and no one can veto a release :) Don Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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] Commented: (STR-2826) If a field's display property is set to 'none' using CSS or JavaScript, the focus code fails.
[
http://issues.apache.org/struts/browse/STR-2826?page=comments#action_37243 ]
Zarar Siddiqi commented on STR-2826:
This worked for me. Thanks. Can't find the option to 'close' this issue so
I'll leave that to you...
If a field's display property is set to 'none' using CSS or JavaScript, the
focus code fails.
-
Key: STR-2826
URL: http://issues.apache.org/struts/browse/STR-2826
Project: Struts Action 1
Type: Bug
Components: Taglibs
Versions: 1.2.9
Environment: Operating System: other
Platform: Other
Reporter: Zarar Siddiqi
Assignee: Don Brown
Fix For: 1.3.3
Attachments: focusControl_css_dispay_bug_fix.patch
If a field's display property is set to 'none' using CSS or JavaScript, the
current code still tries to give the field focus which will result in an error
in IE.
A patch is for the org.apache.struts.taglib.html.FormTag.java file and is
attached:
663c663
if (focusControl.type != \hidden\
!focusControl.disabled) {);
---
if (focusControl.type != \hidden\ !focusControl.disabled
focusControl.style.display != \none\) {);
--
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]
[Struts Wiki] Update of RoughSpots by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Comment on JDK 1.5 -- * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). * [rainerh] +1 for Java 5 support * [tm_jee] +1 + * [niallp] +1 for JDK 1.5 (btw I did a [http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL PROTECTED] POLL on what jdk people used] in Jan). Although it will prevent some users upgrading, maybe for others it will be part of the ''tipping point'' to encourage them to move to 1.5. Also what will the JDK landscape look +1 year from now - I believe most users take their time before upgrading, so thats probably a realistic timescale for the vast majority to consider SAF2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (WW-1293) Tree Tag dont have documentation and examples!
[ http://issues.apache.org/struts/browse/WW-1293?page=all ] tm_jee reassigned WW-1293: -- Assign To: tm_jee Tree Tag dont have documentation and examples! -- Key: WW-1293 URL: http://issues.apache.org/struts/browse/WW-1293 Project: Struts Action 2 Type: Bug Components: Documentation, Examples Versions: WW 2.2.2 Reporter: Mariusz Smykula Assignee: tm_jee Fix For: 2.0 Jason Carreira promise I put an example page in the tutorials and I'll write up some docs for it in the next few days. . We are waiting, we need this! [http://forums.opensymphony.com/thread.jspa?messageID=30591#30591] -- 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: svn commit: r397735 - in /struts/action/trunk/tiles/src: main/resource/META-INF/tld/ tld/
James, shouldn't this be src/main/resource_s_ ? Thanks, Wendy On 4/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jmitchell Date: Thu Apr 27 19:12:59 2006 New Revision: 397735 URL: http://svn.apache.org/viewcvs?rev=397735view=rev Log: making action1 src consistent Added: struts/action/trunk/tiles/src/main/resource/META-INF/tld/ - copied from r397732, struts/action/trunk/tiles/src/tld/ Removed: struts/action/trunk/tiles/src/tld/ - 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] Commented: (STR-2826) If a field's display property is set to 'none' using CSS or JavaScript, the focus code fails.
[
http://issues.apache.org/struts/browse/STR-2826?page=comments#action_37244 ]
Don Brown commented on STR-2826:
Ok, try again, the permissions should be fixed.
If a field's display property is set to 'none' using CSS or JavaScript, the
focus code fails.
-
Key: STR-2826
URL: http://issues.apache.org/struts/browse/STR-2826
Project: Struts Action 1
Type: Bug
Components: Taglibs
Versions: 1.2.9
Environment: Operating System: other
Platform: Other
Reporter: Zarar Siddiqi
Assignee: Don Brown
Fix For: 1.3.3
Attachments: focusControl_css_dispay_bug_fix.patch
If a field's display property is set to 'none' using CSS or JavaScript, the
current code still tries to give the field focus which will result in an error
in IE.
A patch is for the org.apache.struts.taglib.html.FormTag.java file and is
attached:
663c663
if (focusControl.type != \hidden\
!focusControl.disabled) {);
---
if (focusControl.type != \hidden\ !focusControl.disabled
focusControl.style.display != \none\) {);
--
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] Commented: (WW-1295) Datepicker doesn't work with swedish locale (with workarounds)
[ http://issues.apache.org/struts/browse/WW-1295?page=comments#action_37245 ] Don Brown commented on WW-1295: --- I'm fine with an action2-extens or extras project, but you are right, this issue should be closed since the new date picker doesn't support localization at all (!) 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 Assignee: Rainer Hermanns Fix For: 2.0 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: ww:datepicker name=aNiceSwedishNameLikeMeatBalls label=aNiceSwedishLabelLikeSmorgasbord language=sv/ -- 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] Assigned: (WW-796) SetTag scope attribute do not put the object to stack if the scope is given.
[ http://issues.apache.org/struts/browse/WW-796?page=all ] tm_jee reassigned WW-796: - Assign To: tm_jee SetTag scope attribute do not put the object to stack if the scope is given. -- Key: WW-796 URL: http://issues.apache.org/struts/browse/WW-796 Project: Struts Action 2 Type: Improvement Components: Views Versions: WW 2.1.7 Environment: tomcat 5.5 Reporter: Benx Shen Assignee: tm_jee Fix For: 2.0 My suggestion: http://forums.opensymphony.com/thread.jspa?threadID=3283tstart=0 -- 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] Assigned: (WW-772) Allow to radio tag to generate only one radio button
[ http://issues.apache.org/struts/browse/WW-772?page=all ] tm_jee reassigned WW-772: - Assign To: tm_jee Allow to radio tag to generate only one radio button Key: WW-772 URL: http://issues.apache.org/struts/browse/WW-772 Project: Struts Action 2 Type: Improvement Reporter: Xavier Defrang Assignee: tm_jee Priority: Minor Fix For: 2.0 Right now, WebWork's radio tag generates a list of radio buttons. This assumption goes a bit too far as in some case you may have optional fields or random HTML in between those widgets. I would expect the following code to generate a two standalone radio button: snip ... ww:radio name=some.property value='choice1' / ... ww:radio name=some.property value='choice2' / ... /snip The radio button should be checked if some.property == value. -- 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] Assigned: (WW-770) Validation should be aware of namespace that action lives in
[ http://issues.apache.org/struts/browse/WW-770?page=all ] tm_jee reassigned WW-770: - Assign To: tm_jee Validation should be aware of namespace that action lives in Key: WW-770 URL: http://issues.apache.org/struts/browse/WW-770 Project: Struts Action 2 Type: Improvement Components: Actions, Misc Versions: WW 2.1.7 Reporter: Alex Shneyderman Assignee: tm_jee Priority: Trivial Fix For: 2.0 Currently validation forum is unaware of the namespace that the action lives in. It is extremly useful to enable this awarnese, whne actions are being reused and are named exactly the same way in different namespaces. Say we have an application that is editing a few different entityes. We write one generic Save action. We configure pacakges like so: package name=com.mycompany.entity1 namespace=/section/entity1 action name=save class=com.mycompany.actions.Save / /package package name=com.mycompany.entity2 namespace=/section/entity2 action name=save class=com.mycompany.actions.Save / /package to access the actions from the web one would submit the URL /ctx/section/entity1/save.action or /ctx/section/entity2/save.action to save entity1 or entity2. Validation however is different for each of the entities and there is no way to specify validation file that will differentiate between the two saves. Note also that changing the name of the save action is not desitrable, since if you have some kind of automation script to generate the URL you want the config to be as uniform as possible. what would be useful is if we could specify validation files for save like so: Save-%section%entity1-validation.xml and Save-%section%entity1-validation.xml here is a releveant discussion of the forum: http://forums.opensymphony.com/thread.jspa?threadID=1595tstart=0 -- 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] Assigned: (WW-769) UITags do not evaluate id attribute
[ http://issues.apache.org/struts/browse/WW-769?page=all ] tm_jee reassigned WW-769: - Assign To: tm_jee UITags do not evaluate id attribute --- Key: WW-769 URL: http://issues.apache.org/struts/browse/WW-769 Project: Struts Action 2 Type: Bug Components: Views Versions: WW 2.1.7 Reporter: John Patterson Assignee: tm_jee Fix For: 2.0 The UITags inherit the 'id' property from TagSupport which is not evaluated. This means that it cannot be used in a dynamically created form to match a lable to a control. Currently, when I click on a lable they all highlight the same control! I suggest that if no 'id' attribute is specified Webwork should generate a unique identifier from the control name appending a number when there is more than one control of the same name. For example: label for=mycontrolA control/label input type=text name=mycontrol id=mycontrol/ -- 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] Assigned: (WW-711) combobox tag does not support listKey and listValue
[ http://issues.apache.org/struts/browse/WW-711?page=all ] tm_jee reassigned WW-711: - Assign To: tm_jee combobox tag does not support listKey and listValue --- Key: WW-711 URL: http://issues.apache.org/struts/browse/WW-711 Project: Struts Action 2 Type: Improvement Components: Views Versions: WW 2.1.7 Reporter: Quake Wang Assignee: tm_jee Fix For: 2.0 combobox taglib does not support listKey and listValue, and the value can not be keep in the text field. Can we combine the textfield and select tag's features into combobox? -- 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] Assigned: (WW-667) ActionTag executions not subjected to dispose() calls
[ http://issues.apache.org/struts/browse/WW-667?page=all ] tm_jee reassigned WW-667: - Assign To: tm_jee ActionTag executions not subjected to dispose() calls - Key: WW-667 URL: http://issues.apache.org/struts/browse/WW-667 Project: Struts Action 2 Type: Bug Components: Actions, Interceptors, Views Versions: WW 2.1.3 Reporter: Joern Barthel Assignee: tm_jee Priority: Minor Fix For: 2.0 An action called through ww:action/ is subjected to init(), prepare() et. al but not dispose() lifecycle calls. Judging from the javadoc for ActionTag only results should be ignored. -- 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]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Drop several TODOs that are either done, in progress, or in JIRA. -- * Consolidate some of the example apps to reduce the size of the distribution (?Suggested by Don?) * Create a custom deployment plugin to handle promoting our test builds from cvs.apache.org/maven-snapshot-repository to www.apache.org/dist/maven-repository. * http://www.nabble.com/Re%3A-m2-Releases-and-test-builds-p3824610.html - * Finish converting the xdocs to src/site/site.xml and src/site/xdoc, figure out how the Struts Action site will be arranged and put redirects in .htaccess if necessary. * Figure out how to run the Cactus tests in 'integration/el-it' against the strutsel-exercise-taglib webapp which is in the 'apps' module. * http://www.nabble.com/Cargo-and-Maven-2-and-Cactus-t1420342.html * Fix the Cactus tests for Struts Taglib * Revisit the war plugin configuration for including the source code in the example webapps under WEB-INF/src. This is currently being done with an execution of the antrun plugin in apps/pom.xml. Martin mentions that a webResources element is present in the war plugin source, but it does not appear to be available in the latest released version. * http://www.nabble.com/-m2-Including-the-source-code-in-a-war-t1409417.html * http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html - * Document the Struts Maven 2 release process: StrutsMavenRelease - * Integration tests for the webapps under various container/JDK combinations - * Remove the Tiles dependency from EL (Move the tiles-el tags to Struts Tiles) - * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. + * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. (A brief look says there isn't as much duplication as I thought; this might not be necessary.) - * Add reporting section to action/trunk/pom.xml and generate Javadoc and other reports for the website. - * Reorganize any files found in conf/java and src/conf into src/main/resources and remove the resource tags from pom.xml. - * Update the Struts Action Blank Archetype (groupId dependencies) and move it out of the sandbox to action/archetypes/action-blank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-2826) If a field's display property is set to 'none' using CSS or JavaScript, the focus code fails.
[ http://issues.apache.org/struts/browse/STR-2826?page=all ]
Zarar Siddiqi closed STR-2826:
--
This is now fixed.
If a field's display property is set to 'none' using CSS or JavaScript, the
focus code fails.
-
Key: STR-2826
URL: http://issues.apache.org/struts/browse/STR-2826
Project: Struts Action 1
Type: Bug
Components: Taglibs
Versions: 1.2.9
Environment: Operating System: other
Platform: Other
Reporter: Zarar Siddiqi
Assignee: Don Brown
Fix For: 1.3.3
Attachments: focusControl_css_dispay_bug_fix.patch
If a field's display property is set to 'none' using CSS or JavaScript, the
current code still tries to give the field focus which will result in an error
in IE.
A patch is for the org.apache.struts.taglib.html.FormTag.java file and is
attached:
663c663
if (focusControl.type != \hidden\
!focusControl.disabled) {);
---
if (focusControl.type != \hidden\ !focusControl.disabled
focusControl.style.display != \none\) {);
--
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]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
The comment on the change is:
Add notes on the apps-it module
--
'''NOTE:''' The 'assembly:assembly' goal must be run from action/assembly.
Somehow, this needs to be coordinated with release:prepare and release:perform,
so that the assembly will contain the same jars that were just deployed to the
repository.
-
- === Source Assembly ===
-
- * The source code is included in struts-action-x.x.x-all.zip.
-
- * Wait for v2.1 of maven-assembly-plugin, then consider switching to the
action/assembly/src/main/assembly/src.xml and dep.xml descriptors for separate
-bin and -src assemblies.
-
- * See StrutsMaven2Plan for some additional thoughts on assemblies.
-
== Integration Testing ==
The Maven 2
[http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
build lifecycle] includes a phase for integration testing. Currently, a module
may contain only unit tests ''or'' integration tests, but not both. See the
[http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies
testing strategies] page for discussion and proposals.
@@ -88, +79 @@
=== Apps ===
- Tests for the '''apps''' module are not currently automated with Maven 2.
+ The integration/apps-it module contains tests to confirm that each example
app starts and displays its default page:
+ {{{
+~/svn/struts/current/action/integration/apps-it
+mvn -P perform-itest
+ }}}
- However, each module inherits Cargo plugin configuration (from apps/pom.xml)
which will start Tomcat 5.x and deploy the app:
+ In addition, each module inherits Cargo plugin configuration (from
apps/pom.xml) which will start Tomcat 5.x and deploy the app:
{{{
+ ~/svn/struts/current/action/apps/[module]
mvn package cargo:start
}}}
Then visit http://localhost:8080/webappname in your browser. This requires
that the cargo.tomcat5x.home system property is set, usually either on the
command line (-Dcargo.tomcat5x.home=...) or in ~/.m2/settings.xml. See the
Suggested Settings section, below.
@@ -133, +129 @@
profile
idcargo-config/id
properties
-
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.16/cargo.tomcat5x.home
+
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.17/cargo.tomcat5x.home
cargo.tomcat4x.homec:/java/jakarta-tomcat-4.1.31/cargo.tomcat4x.home
/properties
/profile
@@ -161, +157 @@
== References ==
* [http://www.developer.com/open/article.php/10930_3552026_2 This article]
provides a good introduction to Maven 2 and lists some other useful goals.
+ * StrutsMavenRelease
== TODO ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.2 Quality
On 4/28/06, Don Brown [EMAIL PROTECTED] wrote: That makes sense, especially since we don't have an RC quality option. I wonder if we should add it, because there should be a way to indicate the code is pretty complete, stable, and free of major bugs, but at the same time, it isn't GA and is missing key ingredients like documentation and minor bug fixings. Again, to me, a Release Candidate is a distribution that we think we could vote onto GA without change, if wider testing does not uncover any showstoppers. It's a candidate for a GA release. Sure, the binary might be code complete and production ready (or not I haven't sorted through the thirty open issues), but that doesn't make the distribution ready for prime time. Of course, the binaries in our builds are usually production ready. Many people have been using the nightly build in production for six months or a year. The difference between a build and release is that we've included all the other key ingredients we need to turn an entree into a meal. :) -Ted. Don But, that's OK. I'm not the only one with a vote, and no one can veto a release :) Don Ted Husted wrote: +1 Alpha As Don mentioned, some of the documenation is patchy. There are things like references to Bugzilla. The links to the Components, like Extras, need to be fleshed out, the Core link is useless, and we need some introductory text for Taglibs. I might have some time to work on this Monday afternoon, if no one beats me to it. There are a few outstanding bugs in JIRA that should be addressed in the next release. Could you add the bugs you have in mind to the 1.3.2 release plan as known issues? Or, start a 1.3.3 plan that itemizes these. There are 28 open bugs in JIRA now, though I think some of these could be reclassified. But at first glance, 28 is 28 too many for anything except an Alpha :) -Ted. On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r397735 - in /struts/action/trunk/tiles/src: main/resource/META-INF/tld/ tld/
Wow good catch!! I'll fix now. -- James Mitchell On Apr 28, 2006, at 12:05 PM, Wendy Smoak wrote: James, shouldn't this be src/main/resource_s_ ? Thanks, Wendy On 4/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jmitchell Date: Thu Apr 27 19:12:59 2006 New Revision: 397735 URL: http://svn.apache.org/viewcvs?rev=397735view=rev Log: making action1 src consistent Added: struts/action/trunk/tiles/src/main/resource/META-INF/tld/ - copied from r397732, struts/action/trunk/tiles/src/tld/ Removed: struts/action/trunk/tiles/src/tld/ - 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]
svn commit: r397958 - in /struts/action/trunk/tiles/src/main: resource/ resources/
Author: jmitchell Date: Fri Apr 28 10:22:27 2006 New Revision: 397958 URL: http://svn.apache.org/viewcvs?rev=397958view=rev Log: Fix misspelled directory -- Thanks for catching that Wendy\! Added: struts/action/trunk/tiles/src/main/resources/ - copied from r397860, struts/action/trunk/tiles/src/main/resource/ Removed: struts/action/trunk/tiles/src/main/resource/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Add link to the Maven book -- == References == + * [http://www.mergere.com/m2book_download.jsp Better Builds With Maven] - free book from Mergere (requires registration) * [http://www.developer.com/open/article.php/10930_3552026_2 This article] provides a good introduction to Maven 2 and lists some other useful goals. * StrutsMavenRelease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r397973 - /incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/
Author: mrdon Date: Fri Apr 28 11:10:15 2006 New Revision: 397973 URL: http://svn.apache.org/viewcvs?rev=397973view=rev Log: Adding the Apache copyright beside the pico copyright Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionInvocation.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionProxyFactory.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactory.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactoryFilter.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoServletDispatcher.java incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoStrutsServletDispatcher.java Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionInvocation.java URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionInvocation.java?rev=397973r1=397972r2=397973view=diff == --- incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionInvocation.java (original) +++ incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionInvocation.java Fri Apr 28 11:10:15 2006 @@ -1,3 +1,20 @@ +/* + * $Id$ + * + * Copyright 2006 The Apache Software Foundation. + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ /* * Copyright (C) NanoContainer Organization. All rights reserved.* * - * Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionProxyFactory.java URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionProxyFactory.java?rev=397973r1=397972r2=397973view=diff == --- incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionProxyFactory.java (original) +++ incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoActionProxyFactory.java Fri Apr 28 11:10:15 2006 @@ -1,3 +1,20 @@ +/* + * $Id$ + * + * Copyright 2006 The Apache Software Foundation. + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ /* * Copyright (C) NanoContainer Organization. All rights reserved.* * - * Modified: incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactory.java URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactory.java?rev=397973r1=397972r2=397973view=diff == --- incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactory.java (original) +++ incubator/webwork2/action/src/main/java/org/apache/struts/action2/pico/PicoObjectFactory.java Fri Apr 28 11:10:15 2006 @@ -1,3 +1,20 @@ +/* + * $Id$ + * + * Copyright 2006 The Apache Software Foundation. + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language
[Struts Wiki] Update of RoughSpots by JasonCarreira
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by JasonCarreira: http://wiki.apache.org/struts/RoughSpots -- 1. Do we want to keep `ModelDriven`? * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. * [plightbo] I think we should give some serious thought to this. Look around the internal implementation of WebWork/XWork as well as the number of questions that come up on the mailing lists. It's a very confusing thing, especially when interacting with setting or getting values of form fields. + * [jcarreira] yes, it makes the internal implementation more complex, but it makes things easier for the user of the framework in a lot of cases. If people are confused by it, they can choose not to use it. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -266, +267 @@ 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic Environment api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. * [plightbo] +1. we should keep this in mind when designing the API. + * [jcarreira] -1 to using the HttpServletRequest... Why do we need it? We've got a nice abstraction with the Maps for parameters, session, and application scopes, I think. Why tie to the servlet API and make a phony one to proxy to Portlets? 1. Add action and method attributes to the submit button tag so users don't have to know about the action:Name and method:name conventions. * [plightbo] We already do this :) @@ -296, +298 @@ * [jcarreira] I think we should have some pre-defined ones for standard things: view vs. CRUD vs. action - do somthing that's not CRUD. We should then use annotations to make it where you can declaratively associate a particular action method with a stereotype which is mapped to an interceptor stack, etc. * [crazybob] C[R]UD isn't a good name because view == [R]etrieve. Let's call it update for the moment. What will the difference be between update and action? * [plightbo] I really don't think having a update and action stack is a good idea. Let's make a single stack and then have the stack behave differently depending on the context in which the action was executed. There are several options (GET vs POST, method names, annotations, etc). + * [jcarreira] I really think this is a bad idea and will lead to great suffering... We put in interceptors to allow people to customize the processing of a request, why move away from that now? I think if we do some thinking we can think of the common use-cases that cover 80+% of the action cases, and make it very easy for an action developer to tag this action as using one of that small number of stereotypical uses. The action will then pick up the configuration set up for that stereotype (which could include things like defaulting the result pages to go to, etc.) == Gabe's Issues == 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name=view* where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the
[VOTE] Accept and Graduate WebWork 2 Podling to Struts
I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 Git 'r dun!! -- James Mitchell On Apr 28, 2006, at 2:19 PM, Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 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: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
Question: looking at the status page, I don't seem to find any mention of some of the licensing issues that were being discussed a while back... IIRC, there was some concern about a calendar widget for example, among other things. Am I just missing it on the page? Or have they not been resolved? Am I correct in thinking that would keep it from graduating? I give a qualifed and of course non-binding +0, contingent on those issues having been resolved (not sure I could give it a +1, based on the definition of +1 given in this case, but I'm in favor of this happening, that's the pertinent sentiment I think). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Fri, April 28, 2006 2:19 pm, Don Brown said: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 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: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
All those issues have been resolved, but are not listed specifically in that status page. They are covered under the IP checklist, however. Don Frank W. Zammetti wrote: Question: looking at the status page, I don't seem to find any mention of some of the licensing issues that were being discussed a while back... IIRC, there was some concern about a calendar widget for example, among other things. Am I just missing it on the page? Or have they not been resolved? Am I correct in thinking that would keep it from graduating? I give a qualifed and of course non-binding +0, contingent on those issues having been resolved (not sure I could give it a +1, based on the definition of +1 given in this case, but I'm in favor of this happening, that's the pertinent sentiment I think). Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28608messageID=55540#55540 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Suggestion: Google Calendar for Struts
I'd like to suggest we create a Google calendar for Struts upcoming events that people can then subscribe to via RSS or iCal, as well as have the Wiki, etc subscribe to it and show the upcoming events on a public page. I mainly suggest Google Calendar 'cause Bob's been around and we have to make him feel good about his employer ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28611messageID=55541#55541 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion: Google Calendar for Struts
+1 Add a link on the wiki Don Jason Carreira wrote: I'd like to suggest we create a Google calendar for Struts upcoming events that people can then subscribe to via RSS or iCal, as well as have the Wiki, etc subscribe to it and show the upcoming events on a public page. I mainly suggest Google Calendar 'cause Bob's been around and we have to make him feel good about his employer ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28611messageID=55541#55541 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+0. I'd say +1, but it looks like it will be a bit before I have a chance to get more involved. Greg On Apr 28, 2006, at 1:19 PM, Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 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]
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. * [plightbo] Let's not dismiss Tim's comments too quickly. While we might not implement a solution exactly like he suggests, his point is valid that handling state management in WebWork has always been a very week area. The ScopeInterceptor isn't a great option either, especially considering one of my other issues specifically asks that we avoid having to create custom interceptor stacks for various actions. * [jcarreira] I'm open to hearing good ideas for state management. Especially short-lived wizard type state. Long lived session state (things like your user profile) work really well as Spring session-scoped components, but state which is just used for the next 4 or 5 pages isn't such a good fit. + * [MJ] I think talking in terms of pages does not really get us further from ancient SAF1 practices. A web resource can have one view (page) or ten. A wizard can have ten pages defined, but it can use only 3 or 5 of them depending on current state and transitions. It is better to think in terms of web resources, and when it goes out of scope. A wizard is a distinct web resource, who cares how many pages it has. I have built a wizard engine a year ago, and it proved its viability and robustness. No XML, by the way. Check the [http://www.superinterface.com/wizard/signupWizard.do sample]. Try to break it with Reload, Back and Forward buttons. The wizard code hasn't been changed for almost a year, which shows the maturity. I can provide the code and the docs if there is interest. I know that Tim as well as Jason dislike session-scoped data. I hope you guys change your point of view. + * [MJ] In regards to wizards and Redirect-After-Post pattern, does Webwork have something like FlashScope? FlashScope works for only one redirect call, so there may be something longer than FlashScope, but shorter than session. At best, it would be great if a stateful component like a wizard, could be assigned to its own FlashScope+ . 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion: Google Calendar for Struts
Awesome! That's even better than the wiki. -- James Mitchell On Apr 28, 2006, at 2:50 PM, Don Brown wrote: +1 Add a link on the wiki Don Jason Carreira wrote: I'd like to suggest we create a Google calendar for Struts upcoming events that people can then subscribe to via RSS or iCal, as well as have the Wiki, etc subscribe to it and show the upcoming events on a public page. I mainly suggest Google Calendar 'cause Bob's been around and we have to make him feel good about his employer ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa? threadID=28611messageID=55541#55541 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
Jason Carreira wrote: +1 I wonder... has anybody in the history of this whole incubator thing who was getting incubated ever vote against being graduated? As in: Hey, I wanna stay in here longer... it's nice and warm... or... I don't think I quite get the Apache Way yet. I need to get incubated some more... LOL Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28608messageID=55540#55540 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles: Status and Call for Help
On 3/21/06, Greg Reddin [EMAIL PROTECTED] wrote: As for the test cases, I'm not very familiar with Cactus or some other web app testing packages. So to save time, I've been testing using a simple web application and clicking through. ... I can also check my test app into the sandbox if it will help. Maybe someone can go ahead and start the process of converting them to Cactus or whatever they need to be. Craig mentioned HtmlUnit, which we're now using with Cargo to confirm that each Action 1 example app will at least deploy and display its default page. If you'll check in the app you mentioned, I'll add a simple test and you can try it out. Warning: it might require a little rearranging for Maven 2. :) Cactus tests are beyond me at this point, I still haven't figured out why the ones for Struts Taglib don't work. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standalone Tiles] Progress
Oh yeah, hidden in that last commit... Since I was changing the Controller interface anyway, I went ahead and got rid of the perform () method. It was deprecated and needed to go away eventually. Please let me know if anyone has serious issues with that. Greg On Apr 28, 2006, at 3:03 PM, Greg Reddin wrote: I've added a preliminary version of a TilesContext interface and refactored the core API to use it. The interface is a first attempt at extracting the Servlet API dependencies. Here are some more details: I debated about whether to model TilesContext after Commons-Chain's WebContext or JSF's ExternalContext. WebContext seemed a bit more applicable so I started with a very similar interface. I then added a few more methods mostly modeled after ExternalContext. I created a factory and a Servlet-based implementation just to get the tests to pass. I suspect the factory and the way it's being used to change significantly after I look further at the way Faces and Chain use their context classes in various environments. Note that I ran out of time before I had a chance to look at these other examples, so if you look at what I just committed and inherently see a better way, please share. I have not tested this at all other than the provided unit tests, so it probably doesn't work :-) I'm just trying to push something through before I have to take off for the weekend so some progress is being made. I'd love it if some others would look at my most recent commit and give me some advice on how to improve it. Starting next week I hope to be able to flesh this all out further. This is the last refactoring step that is needed before the Standalone Tiles API will be stable. Yippe! If I don't respond to any emails for a while it's because I'm going out of town for the weekend, but I'll check back in on Monday. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+0 (non-binding) with the same caveat. L. Greg Reddin wrote: +0. I'd say +1, but it looks like it will be a bit before I have a chance to get more involved. Greg On Apr 28, 2006, at 1:19 PM, Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 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: Standalone Tiles: Status and Call for Help
Speaking of testing.I recently came across a really cool plugin for FireFox. It's called TestGen4Web and it let's you record and save a browser session. feedback type=anticipated What the heck is a browser session? /feedback Oh, I'm glad you asked. It is the set of step that you (as a user) do within a browser window. You can then have the saved session (which is in xml by the way) converted to an HttpUnit test. https://addons.mozilla.org/firefox/1385/ -- James Mitchell On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote: On 3/21/06, Greg Reddin [EMAIL PROTECTED] wrote: As for the test cases, I'm not very familiar with Cactus or some other web app testing packages. So to save time, I've been testing using a simple web application and clicking through. ... I can also check my test app into the sandbox if it will help. Maybe someone can go ahead and start the process of converting them to Cactus or whatever they need to be. Craig mentioned HtmlUnit, which we're now using with Cargo to confirm that each Action 1 example app will at least deploy and display its default page. If you'll check in the app you mentioned, I'll add a simple test and you can try it out. Warning: it might require a little rearranging for Maven 2. :) Cactus tests are beyond me at this point, I still haven't figured out why the ones for Struts Taglib don't work. Thanks, -- 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: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 On 4/28/06, Don Brown [EMAIL PROTECTED] wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 Show time ! On 4/28/06, Laurie Harper [EMAIL PROTECTED] wrote: +0 (non-binding) with the same caveat. L. Greg Reddin wrote: +0. I'd say +1, but it looks like it will be a bit before I have a chance to get more involved. Greg On Apr 28, 2006, at 1:19 PM, Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 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] -- Java/XML Programmer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods
Re: [action2] Confluence migration next step: Migrate content
On the confluence instance, can we put something in either the from address or tagline so that we know its from the Apache Struts confluence instance. Right now, it just says [EMAIL PROTECTED] and [confluence]', which would be problematic if other projects use Confluence too. (And I know some of mine will!) -Ted. On 4/23/06, Don Brown [EMAIL PROTECTED] wrote: 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]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 from me and a big thank you to everyone involved On Apr 28, 2006, at 20:19 , Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (WW-1281) Allow StreamResult parameters to be read from the stack
Rene, let me know what you think of this. I have a slightly different direction that I've been poking around with that takes the same idea a bit further. Too often I find myself wishing to just use a value on the stack for configuration and not poke around in the XML. I'd like a generic way to declare parameters that will automagically get pulled from the stack (If available). I probably need to put that under a nice to have but the more I work with complex logic in Webwork, the more I feel constrained by the XML. Cheers On 4/28/06, Rene Gielen (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/struts/browse/WW-1281?page=all ] Rene Gielen reassigned WW-1281: --- Assign To: Rene Gielen Allow StreamResult parameters to be read from the stack --- Key: WW-1281 URL: http://issues.apache.org/struts/browse/WW-1281 Project: Struts Action 2 Type: Improvement Components: Views, Configuration, Dispatch Versions: WW 2.2.2 Environment: Any Reporter: Eric Molitor Assignee: Rene Gielen Fix For: 2.0 Attachments: StreamResult.patch This patch allows the parameters for the stream result to be read from the stack. I seem to be having issues running the unit tests so none are included. (I'll probably work on some later). Precedence is given to values on the stack over values in the XML file. I plan to use the patch as follows In xwork.xml I create a global stream result.. result name=stream type=stream / Then in my actions I create getter methods for the various parameters (probably just contentDisposition, contentType, and contentLength) and then just return stream as the result of my execute method. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Confluence migration next step: Migrate content
Were we able to get the snippet macro setup so that it can access the ASF repository? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Confluence migration next step: Migrate content
I believe Patrick took care of that. Don Ted Husted wrote: Were we able to get the snippet macro setup so that it can access the ASF repository? -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] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]
So, after a long winded discussion on the WW Chat line(no need to rehash, it's in your inbox -- or will be)... several ideas were mentioned, and so I thought I'd throw it out there for comment. Patrick has graciously offered to provide the Struts community with free beer and back rubs woo hooo!!! - ok, just kidding about the beer. Patrick has offered us free resources for automated testing. I'll let Patrick explain in greater detail as I'm not that familiar with what he has to offer and I don't want to misquote. The discussion (as you've read from the chat) originally started just as chatter about the below plugin (TestGen4Web) and what we could do with it to help with automated testing. There is plenty of documentation out there for TestGen4Web, but let me explain how this thing works and where I think we can leverage it for our own needs. TestGen4Web is a FireFox plugin that let's you record a session (as mentioned below). Once you push record, everything you do is remembered and you can save the file locally right from the toolbar. You can even load an existing script and play it. If you have downloaded the translator, you can generate an HttpUnit java source from the saved .xml file that implements everything you did with the mouse and keyboard that is a ready to run HttpUnit test class. For example, this is what is generated when I recorded a session for the struts-blank application: ?xml version='1.0' encoding='UTF-8'? tg4w version=0.38.1 actions action type=goto refresh=true step=0 xpath![CDATA[window.location.href]]/xpath value![CDATA[http://localhost:8080/struts-blank/]]/ value /action action type=verify-title refresh=true step=1 xpath![CDATA[*]]/xpath value![CDATA[Struts Blank Application]]/value /action action type=assert-text-exists step=2 xpath![CDATA[*]]/xpath value![CDATA[Welcome!]]/value /action /actions /tg4w You can see in step 0 I hit the url for the struts-blank app. Then in step 1 the title is verified and step 2 verifies that the text Welcome! is in the page. I did step 2 (assert-text-exists) by highlighting the Welcome! text and right click - Assert - Verify Text. The same .xml file can also be used to generate a Selenium configuration xml file that does the same test. Currently there isn't a Maven 2 plugin for the process of translating from xml to java and that's where I come in. What comes with TestGen4Web is an ant build that does the job. I'm currently working on a new Maven 2 plugin that handles this and it should be finished by the time you read this. Configuring the test to run as part of the build will be the tricky (Wendy? help?!?!) part. With this plugin, you won't have to download the translator. Like most things in Maven, you aren't forced into a directory structure, but for this purpose I propose we do this: struts + action + apps + blank + cookbook + ... + ... + TestGen4Web + src + main + scripts - new (.xml) scripts go here + target + gensrc - scripts get gen'd to here (.java) + classes- the plugin would compile the test to here (Just to be clear, the only thing we should be keeping in svn is the xml scripts) This plugin will generate both HttpUnit (.java) and Selenium (.xml) sources, and this would is where Patrick's process could pick up the Selenium config. And so, going forward with this plugin, all we would need to do is create a new script (e.g. blank-validate-welcome.xml) and put it under TestGen4Web/src/main/scripts and you are done. Obviously we would want to be consistent with script naming, personally I would prefer that they be verbose and in the event that a new script is needed to verify a specific bug, the bug number might also be in the name. One other option we might consider is keeping a README.txt in that directory if any further details are needed. These scripts would greatly speed up the release process since it would basically do the equivalent of about 2 or more hours of what used to be done manually. However, the fun doesn't stop here. I'm not sure how clear I was in the chat log about my idea for a linear set of pages to test the taglibs, but what I had in mind would be to extend the cookbook and provide many more examples that demonstrate the various ways some tags can be used. I'm not sure if we want to go the same route as the taglib tests by providing a test for every possible combination of attributes for every tag and some with multiple scenarios for tags that supported different ways to provide values for a given attribute. Whatever the case, I'm excited about being able to add new tests that are also directly adding to the demo apps / tutorials.
Re: Suggestion: Google Calendar for Struts
So who's account do we want to create it under? I suppose we can give permissions to multiple people to maintain calendar events and user permissions... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28611messageID=55602#55602 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (STR-2850) Add tests to confirm that example apps work
[ http://issues.apache.org/struts/browse/STR-2850?page=comments#action_37247 ] Wendy Smoak commented on STR-2850: -- See also: http://www.nabble.com/-action1-Improving-our-testslong-was-Re%3A-Standalone-Tiles%3A-Status-and-Call-for-Help--p4150894.html Add tests to confirm that example apps work --- Key: STR-2850 URL: http://issues.apache.org/struts/browse/STR-2850 Project: Struts Action 1 Type: Improvement Components: Apps Versions: Nightly Build Reporter: Wendy Smoak Assignee: Wendy Smoak Priority: Minor Fix For: 1.3.3 Simple automated tests using HtmlUnit and Cargo, to confirm that each example app deploys, starts, and displays its default page. -- 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: [action1] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]
One thing that I might have blurred the lines on is that there are basically 2 things being proposed here with respect to TestGen4Web. #1 - The ability to easily create test scripts for cases that can only be proven and solved via a deployed app (and without cactus) #2 - A set of scripts (that happen to be executed just like #1, yet serve a little different purpose) that recursively run through the cookbook links and assert success on the page after every click. While the existing cookbook pages usually offer some kind of interactivity (enter some data and see it work differently for different values), the new pages that demonstrate the taglibs (or test them, depending on your purpose) would be required to show some kind of success message that can be asserted. That value should not appear if the test fails. The success message will need to be consistent if the tests are to be recursive. Meaning that adding new tests (recipes) to an existing page (chapter) would only require that a new description and link be added and when clicked on will end up showing a page where the text could be asserted. Again, that applies to the pages that test (and demonstrate) taglibs. So, to mentally reorg the cookbook. Instead of this: -- Simple Form using ActionForm Execute - link that gets clicked and tested Simple Form using DynaActionForm Execute - same Select and Options tags Execute - same ... (and on down the page) ... -- We might have a Table of contents as an index that links to pages like the one above. If no one objects, I'll proceed on it. -- James Mitchell On Apr 28, 2006, at 11:36 PM, James Mitchell wrote: So, after a long winded discussion on the WW Chat line(no need to rehash, it's in your inbox -- or will be)... several ideas were mentioned, and so I thought I'd throw it out there for comment. Patrick has graciously offered to provide the Struts community with free beer and back rubs woo hooo!!! - ok, just kidding about the beer. Patrick has offered us free resources for automated testing. I'll let Patrick explain in greater detail as I'm not that familiar with what he has to offer and I don't want to misquote. The discussion (as you've read from the chat) originally started just as chatter about the below plugin (TestGen4Web) and what we could do with it to help with automated testing. There is plenty of documentation out there for TestGen4Web, but let me explain how this thing works and where I think we can leverage it for our own needs. TestGen4Web is a FireFox plugin that let's you record a session (as mentioned below). Once you push record, everything you do is remembered and you can save the file locally right from the toolbar. You can even load an existing script and play it. If you have downloaded the translator, you can generate an HttpUnit java source from the saved .xml file that implements everything you did with the mouse and keyboard that is a ready to run HttpUnit test class. For example, this is what is generated when I recorded a session for the struts-blank application: ?xml version='1.0' encoding='UTF-8'? tg4w version=0.38.1 actions action type=goto refresh=true step=0 xpath![CDATA[window.location.href]]/xpath value![CDATA[http://localhost:8080/struts-blank/]]/ value /action action type=verify-title refresh=true step=1 xpath![CDATA[*]]/xpath value![CDATA[Struts Blank Application]]/value /action action type=assert-text-exists step=2 xpath![CDATA[*]]/xpath value![CDATA[Welcome!]]/value /action /actions /tg4w You can see in step 0 I hit the url for the struts-blank app. Then in step 1 the title is verified and step 2 verifies that the text Welcome! is in the page. I did step 2 (assert-text-exists) by highlighting the Welcome! text and right click - Assert - Verify Text. The same .xml file can also be used to generate a Selenium configuration xml file that does the same test. Currently there isn't a Maven 2 plugin for the process of translating from xml to java and that's where I come in. What comes with TestGen4Web is an ant build that does the job. I'm currently working on a new Maven 2 plugin that handles this and it should be finished by the time you read this. Configuring the test to run as part of the build will be the tricky (Wendy? help?!?!) part. With this plugin, you won't have to download the translator. Like most things in Maven, you aren't forced into a directory structure, but for this purpose I propose we do this: struts + action + apps + blank + cookbook + ... + ... + TestGen4Web + src + main + scripts - new
Re: Suggestion: Google Calendar for Struts
Go for it! -- James Mitchell On Apr 28, 2006, at 11:45 PM, Jason Carreira wrote: So who's account do we want to create it under? I suppose we can give permissions to multiple people to maintain calendar events and user permissions... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa? threadID=28611messageID=55602#55602 - 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: Suggestion: Google Calendar for Struts
On 4/28/06, Jason Carreira [EMAIL PROTECTED] wrote: So who's account do we want to create it under? I suppose we can give permissions to multiple people to maintain calendar events and user permissions... How about if we ask the PMC Chair (Martin at the moment) to create a pseudo-account for this purpose (so that it's not tied to any particular person), and then share the password appropriately? Craig
[jira] Created: (STR-2852) Move the non-working integration tests to the sandbox for review.
Move the non-working integration tests to the sandbox for review. - Key: STR-2852 URL: http://issues.apache.org/struts/browse/STR-2852 Project: Struts Action 1 Type: Improvement Versions: Nightly Build Reporter: Wendy Smoak Assigned to: Wendy Smoak Priority: Minor Fix For: 1.3.3 Move the Cactus tests for Struts EL and Struts Taglib to the sandbox. Also move the Struts Faces sysclient-app and systest1-webapp directories. (This is a webapp and HtmlUnit tests for it.) -- 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: Suggestion: Google Calendar for Struts
Oops, I just did that. I called the calendar Planet Struts and put a quick link on the new wiki. Here's the TinyURL version: * http://tinyurl.com/f777e I put the Ti session for JavaOne on the calendar for next month. I'll note the credentials in the Struts committers area of the ASF repository. -Ted. On 4/29/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/28/06, Jason Carreira [EMAIL PROTECTED] wrote: So who's account do we want to create it under? I suppose we can give permissions to multiple people to maintain calendar events and user permissions... How about if we ask the PMC Chair (Martin at the moment) to create a pseudo-account for this purpose (so that it's not tied to any particular person), and then share the password appropriately? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r398084 - /struts/sandbox/trunk/apps-test/
Author: wsmoak Date: Fri Apr 28 21:51:59 2006 New Revision: 398084 URL: http://svn.apache.org/viewcvs?rev=398084view=rev Log: Created folder for the currently non-working Cactus tests, and other test-related files that need to be reviewed. Added: struts/sandbox/trunk/apps-test/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r398085 - in /struts: action/trunk/integration/taglib-it/ sandbox/trunk/apps-test/taglib-it/
Author: wsmoak Date: Fri Apr 28 22:00:40 2006 New Revision: 398085 URL: http://svn.apache.org/viewcvs?rev=398085view=rev Log: Moved the Cactus tests for Struts Taglib to the sandbox. Issue: STR-2852 Added: struts/sandbox/trunk/apps-test/taglib-it/ - copied from r398084, struts/action/trunk/integration/taglib-it/ Removed: struts/action/trunk/integration/taglib-it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
