Re: [VOTE] Struts 1.2.9 Quality
I think that as soon as there is a 1.3 GA release, there would be no reason at all to backport changes to 1.2.x As Michael points out, 1.3 is not a revolutionary change from 1.2 and the migration path is not an extremely complicated one. The recent 1.2.9 release is largely to address specific security concerns which merited a release of something likely to be GA sooner than we could expect 1.3.x to reach that level. Joe Michael J wrote: You think that 1.3 is a revolution? Or a leap so giant that current 1.2.x users may not be able to make? Afaik, 1.3 can be used without knowing anything about chains, with minor web.xml fixes. That is how I used it a while ago. Have this changed? Having stated in another thread that Struts is all about backwards compatibility, 1.3 should serve well to 1.1 and 1.2.x users. I don't see the point in continuing 1.2.x generation. There too many Struts flavors already. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.9 Quality
On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: The difference is that Spring is commercial open source. Here it needs a volunteer willing to do it and the problem with that if eat our own dog food how likely is it there'll be a volunteer wanting to back port? Following up on something Niall said elsewhere, the trick to open source is to concentrate on scratching your own itch. If there's a feature that *you* want implemented for *your* application, go ahead and implement it, and then try to share the wealth. Worst case, you've got a feature that you needed. Ditto for patches and fixes. Worse case, you've patched your copy of the framework so that it works better for you. Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add Struts to Apache Projects site
On 3/16/06, James Mitchell [EMAIL PROTECTED] wrote: Funny, this page: http://projects.apache.org/languages.html ...doesn't mention C#/.Net -- sorry Ted ;) Well, that's certainly an oversite. I've have to submit a patch. Besides my Struts whiteboard, with the foundation we have iBATIS.NET, Logging.NET, and Lucene.NET, not to mention the HTTPD cli module that lets you run .NET under Apache HTTPD. Viva La Revolucion!! -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.9 Quality
This is a great post. I nominate it to be added to the Struts how to contribute section. It's worth sharing in an official matter: the correct attitude of helping. --- Ted Husted [EMAIL PROTECTED] wrote: On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: The difference is that Spring is commercial open source. Here it needs a volunteer willing to do it and the problem with that if eat our own dog food how likely is it there'll be a volunteer wanting to back port? Following up on something Niall said elsewhere, the trick to open source is to concentrate on scratching your own itch. If there's a feature that *you* want implemented for *your* application, go ahead and implement it, and then try to share the wealth. Worst case, you've got a feature that you needed. Ditto for patches and fixes. Worse case, you've patched your copy of the framework so that it works better for you. Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39015] New: - shale-mailreader-20060316.war could not be started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39015. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39015 Summary: shale-mailreader-20060316.war could not be started Product: Struts Version: Nightly Build Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Shale AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] When trying to deploy shale-mailreader-20060316.war, I got the message FAIL - Application at context path /shale-mailreader-20060316 could not be started I am using Apache Tomcat/5.0.19and JVM version 1.4.2_02-b03 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686 i386 GNU/Linux I also get this error: 2006-03-16 15:29:03 StandardContext[/shale-mailreader-20060316]Exception starting filter shale java.lang.UnsupportedClassVersionError: org/apache/shale/tiger/faces/LifecycleListener (Unsupported major.minor version 49.0) When I removed shale-tiger.jar from the WEB-INF/lib (as suggested by Wendy Smoak) the application starts and runs fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39015] - shale-mailreader-20060316.war could not be started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39015. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39015 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-17 15:36 --- Fixed in r386550. http://svn.apache.org/viewcvs?rev=386550view=rev Please try shale-mailreader-20060317.war from http://cvs.apache.org/builds/struts/nightly/struts-shale/ and let us know if you still have problems. It works for me on Tomcat 5.0.28 and JDK 1.4.2. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.9 Quality
On Fri, March 17, 2006 9:15 am, Ted Husted said: Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. I used to say this sort of thing, but I have come to see your point here and largely agree. However, you seem to leave room for another possibility, by using the phrase if so here, and I think that's good, because I don't think it's an either-or proposition... For example, I don't think I've ever said tell me this will be accepted or I won't do it, but certainly I've looked for support for an idea among committers before putting in effort, and I don't see this as a problem. Someone can want to contribute out of an altrusitic mindset, want to see a project move forward in a certain way out of a desire to do good, and for them it might be perfectly valid to not want to wind up wasting their time doing something that was never going to be accepted. Not all good ideas come from scratching an itch is my point. I think it's fair to be weary of an idea not born of that, but it doesn't automatically make it a bad idea, and it doesn't automatically mean the person doesn't have good/non-selfish intentions at heart. Let's not let this thread go any further OT than this though... I still give my non-binding +1 for GA :) -Ted. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39020] New: - Validator validwhen :Cannot make dependance between two different index in an Array
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39020. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39020 Summary: Validator validwhen :Cannot make dependance between two different index in an Array Product: Struts Version: 1.2.8 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Action AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] This code in the validator.xml fails with this error : unexpected token adr.. field property=adr[0] depends =validwhen var var-nametest/var-name var-value((*this*!=null) or (adr[1] != null ))/var-value /var /field adr is an array of two adress lines. Only one of them needs tobe filled. According to the document of the validator, it should work. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39020] - Validator validwhen :Cannot make dependance between two different index in an Array
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39020. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39020 --- Additional Comments From [EMAIL PROTECTED] 2006-03-17 17:02 --- Adding a link to the related thread on the user list: http://www.mail-archive.com/user%40struts.apache.org/msg43177.html I had a quick look at the source (ValidWhenParser.g) and I agree it looks like it should cater for this. I also tried adding a test case (to TestValidWhen.java) to and got the same result as Christophe. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.9 Quality
Frank W. Zammetti wrote: On Fri, March 17, 2006 9:15 am, Ted Husted said: Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. I used to say this sort of thing, but I have come to see your point here and largely agree. However, you seem to leave room for another possibility, by using the phrase if so here, and I think that's good, because I don't think it's an either-or proposition... For example, I don't think I've ever said tell me this will be accepted or I won't do it, but certainly I've looked for support for an idea among committers before putting in effort, and I don't see this as a problem. Someone can want to contribute out of an altrusitic mindset, want to see a project move forward in a certain way out of a desire to do good, and for them it might be perfectly valid to not want to wind up wasting their time doing something that was never going to be accepted. Not all good ideas come from scratching an itch is my point. I think it's fair to be weary of an idea not born of that, but it doesn't automatically make it a bad idea, and it doesn't automatically mean the person doesn't have good/non-selfish intentions at heart. I agree with what you say but I thought that I'd point out that open source projects are successful for their code and not their ideas. So a person may have a fabulous idea but if they aren't going to use the code themselves then it is likely to be of lower quality than something similar that someone is going to use. It's not universally true but the phrase eating your own dog food didn't come from nowhere. :) Scratching an itch implies that not only does one have an idea but they have a use-case that their idea solves... which means their solution will probably be more than a sketch of a good idea. And it's something that they'd want to maintain. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebWork 2 Incubation Status
This is the status of the WebWork 2 Incubation: 1. We have an official Incubator status page at http://incubator.apache.org/projects/webwork2.html 2. March 22 is the scheduled date for the WebWork 2.2.2 release, and subsequent SVN cutover to the Apache Incubator repository. 3. The JIRA cutover is also scheduled for March 22, however, it is less certain as we are dependent on the time of Jeff Turner, the Apache JIRA guy. 4. All but Toby Jee have sent in their CLA's and have been given an Apache account and SVN access. 5. We are still gathering CLA's from non-active WebWork 2 developers and will be throughout Incubation The WebWork 2 team has been working hard this entire time so while it may seem like Action 2 isn't coming along, it has been quite rapidly. The WebWork 2 commits will be sent to this list, so that everyone may be informed of its progress and encouraged to jump in and help the effort. At this time, we are planning three migration paths for Action 1 users: 1. Dual processors, shared resources - Run Action 1 and Action 2 servlets/filters side-by-side sharing resources like messages and validations, allowing a developer to migrate a module or so at a time. 2. Migration tools - These tools would help a developer to migrate their entire application to Action 2 using XSLT stylesheets, an integration library to use existing ActionForms unmodified on Action 2, and possibly an entire port of the Action 1 processing chain to Action 2. 3. Example applications - Ted has been working hard on migrating popular Action 1 applications such as the Mailreader and the iBATIS JPetstore application over to Action 2. This will provide developers an example of Action 2 best practices and a practical example to help them migrate their Action 1 knowledge. Again, welcome WebWork 2 development team and community, and lets try to get this Action 2 out the door ASAP, but no sooner ;) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Shale/Resources 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/Shale/Resources The comment on the change is: Duncan's blog is back - add the dates he posted -- || [http://jroller.com/page/dgeary?entry=shale_adds_web_flow1 Shale Adds Web Flow] || David Geary's Blog || May 2005 || || [http://www.jroller.com/page/dgeary/20050419#added_commons_validator_support_to Shale Adds Validation Support] || David Geary's Blog || April 2005 || || [http://www.jroller.com/page/dgeary/20050321#shale_cometh Shale Cometh] || David Geary's Blog || March 2005 || - || [http://www.groundside.com/blog/content/DuncanMills/J2EE+Development/?permalink=C6020059D201AAC49C5E9106A181C8E6.txt Customising the ViewControllerMapper] || Duncan Mills's Blog || ? || + || [http://www.groundside.com/blog/content/DuncanMills/J2EE+Development/?permalink=C6020059D201AAC49C5E9106A181C8E6.txt Customising the ViewControllerMapper] || Duncan Mills's Blog || March 2005 || - || [http://www.groundside.com/blog/content/DuncanMills/J2EE+Development/?permalink=9074324708A06EE85EE4720495475AA9.txt The ViewController Lifecycle] || Duncan Mills's Blog || ? || + || [http://www.groundside.com/blog/content/DuncanMills/J2EE+Development/?permalink=9074324708A06EE85EE4720495475AA9.txt The ViewController Lifecycle] || Duncan Mills's Blog || March 2005 || === Books (most recent first) === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Shale/Validation 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/Shale/Validation
The comment on the change is:
Copy ShaleValidation page to Shale/Validation
New page:
##language:en
#pragma section-numbers off
||rowbgcolor=#E0[http://struts.apache.org/struts-shale/index.html Shale
Home]||[:Shale:Wiki Home]||[:Shale/UserDocs:User
Docs]||[:Shale/SiteMap:Index]||[:Shale/WikiGuidelines:Guidelines]||[:../:Go
Up]||
-
== Shale Commons Validator Integration ==
* http://struts.apache.org/struts-shale/features-commons-validator
=== Validation error messages and the s:validatorVar tag ===
The parameters used to format the
[http://svn.apache.org/repos/asf/struts/shale/trunk/core-library/src/java/org/apache/shale/validator/messages.properties
error messages] that are shown when a validation error occurs include the
incorrect value and any validator-specific 'var' parameters.
When the s:validatorVar tag is used for validator-specific 'var' parameters,
the order in which the 'var's are declared is the order that will be used to
format the error message.
For a 'range' validator, such as 'floatRange', the error message pattern is:
{{{errors.range={0} is not in the range {1} through {2}.}}}
Therefore, when using a range validator with the s:validatorVar tags,
specify the min var before the max var:
{{{
s:commonsValidator type=floatRange
arg=#{msgs.amount}
server=true
client=false
s:validatorVar name=min value=10/
s:validatorVar name=max value=1000/
/s:commonsValidator
}}}
=== Using Custom Validation Rules with Shale ===
To use a custom validation rule in your application, complete the following
steps:
'''1. Define an xml file conforming to the Commons Validator 1.2.0 dtd.'''
In this example, the file will be named 'custom-rules.xml' and will be placed
in /WEB-INF.
{{{
!DOCTYPE form-validation PUBLIC
-//Apache Software Foundation//DTD Commons Validator Rules
Configuration 1.2.0//EN
http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd;
form-validation
global
validator name=evenNumber
classname=com.example.ValidationUtil
method=isEven
methodParams=int
msg=errors.even
/validator
/global
/form-validation
}}}
'''2. Write the validation method.'''
{{{
package com.example;
public class ValidationUtil implements Serializable
{
public static boolean isEven( int value ) {
return (value % 2 == 0);
}
}
}}}
'''3. Configure the validation rules in web.xml.'''
Include the default rule set by listing
/org/apache/shale/validator/validator-rules.xml in addition to your custom
rules.
{{{
!-- Shale Validator Configuration Resources --
context-param
param-nameorg.apache.shale.validator.VALIDATOR_RULES/param-name
param-value
/org/apache/shale/validator/validator-rules.xml,
/WEB-INF/custom-rules.xml
/param-value
/context-param
}}}
!CommonsValidator will pass the value entered by the user as the first
parameter of your validation method, provided you have listed at least one type
in the 'methodParams' attribute of your validator tag.
In addition, if you add them as attributes to the s:commonsValidator tag,
!CommonsValidator will pass the following parameters through to your validation
method: min, max, minlength, maxlength, mask, and datePatternStrict. These
parameters are always passed in exactly this order, no matter how they are
listed in s:commonsValidator.
'''4. Provide a resource bundle for messages.''' (Optional)
The !CommonsValidator class reads the messages from the application's resource
bundle, then from the 'messages' bundle in org.apache.struts.validator (the
(localized) messages.properties file inside shale-core.jar).
If you can use one of the provided messages for your validator, then no action
is necessary.
If you need to provide additional messages or override any of the provided
messages, here's how:
Configure a resource bundle for your application in faces-config.xml. For
example:
{{{
application
message-bundleApplicationResources/message-bundle
locale-config
default-localeen/default-locale
supported-localeen/supported-locale
/locale-config
/application
}}}
And add your message to it. In this example, the file would be
'/WEB-INF/classes/!ApplicationResources.properties'.
{{{
errors.even={0} is not an even number.
}}}
The value of the field being validated is automatically passed as {0} for
message parameter replacement.
'''5. Attach your new validation rule to a component.'''
In this example, we have a text field called Priority which will only accept
an even number.
{{{
h:outputText value=#{messages['prompt.priority']}/
Re: [VOTE] Struts 1.2.9 Quality
On Fri, March 17, 2006 12:11 pm, Paul Speed said: I agree with what you say but I thought that I'd point out that open source projects are successful for their code and not their ideas. So a person may have a fabulous idea but if they aren't going to use the code themselves then it is likely to be of lower quality than something similar that someone is going to use. It's not universally true but the phrase eating your own dog food didn't come from nowhere. :) Scratching an itch implies that not only does one have an idea but they have a use-case that their idea solves... which means their solution will probably be more than a sketch of a good idea. And it's something that they'd want to maintain. That's a good point Paul, thank you! -Paul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ShaleValidation 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/ShaleValidation
The comment on the change is:
Remove content and re-direct ShaleValidation to Shale/Validation
--
- == Shale Commons Validator Integration ==
+ #REDIRECT Shale/Validation
- * http://struts.apache.org/struts-shale/features-commons-validator
+ This page has moved to [:Shale/Validation] and should automatically re-direct.
- === Validation error messages and the s:validatorVar tag ===
-
- The parameters used to format the
[http://svn.apache.org/repos/asf/struts/shale/trunk/core-library/src/java/org/apache/shale/validator/messages.properties
error messages] that are shown when a validation error occurs include the
incorrect value and any validator-specific 'var' parameters.
-
- When the s:validatorVar tag is used for validator-specific 'var'
parameters, the order in which the 'var's are declared is the order that will
be used to format the error message.
-
- For a 'range' validator, such as 'floatRange', the error message pattern is:
-
- {{{errors.range={0} is not in the range {1} through {2}.}}}
-
- Therefore, when using a range validator with the s:validatorVar tags,
specify the min var before the max var:
-
- {{{
- s:commonsValidator type=floatRange
- arg=#{msgs.amount}
- server=true
- client=false
- s:validatorVar name=min value=10/
- s:validatorVar name=max value=1000/
- /s:commonsValidator
- }}}
-
-
- === Using Custom Validation Rules with Shale ===
-
- To use a custom validation rule in your application, complete the following
steps:
-
- '''1. Define an xml file conforming to the Commons Validator 1.2.0 dtd.'''
-
- In this example, the file will be named 'custom-rules.xml' and will be placed
in /WEB-INF.
-
- {{{
- !DOCTYPE form-validation PUBLIC
- -//Apache Software Foundation//DTD Commons Validator Rules
Configuration 1.2.0//EN
- http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd;
- form-validation
-global
-validator name=evenNumber
- classname=com.example.ValidationUtil
- method=isEven
- methodParams=int
- msg=errors.even
-/validator
-/global
- /form-validation
- }}}
-
- '''2. Write the validation method.'''
-
- {{{
- package com.example;
- public class ValidationUtil implements Serializable
- {
- public static boolean isEven( int value ) {
-return (value % 2 == 0);
- }
- }
- }}}
-
- '''3. Configure the validation rules in web.xml.'''
-
- Include the default rule set by listing
/org/apache/shale/validator/validator-rules.xml in addition to your custom
rules.
-
- {{{
- !-- Shale Validator Configuration Resources --
- context-param
-param-nameorg.apache.shale.validator.VALIDATOR_RULES/param-name
-param-value
-/org/apache/shale/validator/validator-rules.xml,
-/WEB-INF/custom-rules.xml
-/param-value
- /context-param
- }}}
-
- !CommonsValidator will pass the value entered by the user as the first
parameter of your validation method, provided you have listed at least one type
in the 'methodParams' attribute of your validator tag.
-
- In addition, if you add them as attributes to the s:commonsValidator tag,
!CommonsValidator will pass the following parameters through to your validation
method: min, max, minlength, maxlength, mask, and datePatternStrict. These
parameters are always passed in exactly this order, no matter how they are
listed in s:commonsValidator.
-
- '''4. Provide a resource bundle for messages.''' (Optional)
-
- The !CommonsValidator class reads the messages from the application's
resource bundle, then from the 'messages' bundle in org.apache.struts.validator
(the (localized) messages.properties file inside shale-core.jar).
-
- If you can use one of the provided messages for your validator, then no
action is necessary.
-
- If you need to provide additional messages or override any of the provided
messages, here's how:
-
- Configure a resource bundle for your application in faces-config.xml. For
example:
-
- {{{
- application
- message-bundleApplicationResources/message-bundle
- locale-config
- default-localeen/default-locale
- supported-localeen/supported-locale
- /locale-config
- /application
- }}}
-
- And add your message to it. In this example, the file would be
'/WEB-INF/classes/!ApplicationResources.properties'.
-
- {{{
- errors.even={0} is not an even number.
- }}}
-
- The value of the field being validated is automatically passed as {0} for
message parameter replacement.
-
- '''5. Attach your new validation rule to a component.'''
svn commit: r386676 - in /struts/sandbox/trunk/action2/apps/cookbook/src: java/ java/cookbook2/ java/cookbook2/actiontag/ java/cookbook2/pojo/ webapp/WEB-INF/classes/ webapp/pages/Pojo/
Author: husted
Date: Fri Mar 17 09:50:38 2006
New Revision: 386676
URL: http://svn.apache.org/viewcvs?rev=386676view=rev
Log:
Action2 Apps
* Move configurations to Java package tree, to keep more things together.
Added:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/Hello-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Hello-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/Home-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Home-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/Select-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Select-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/Simple-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Simple-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/ActionTag-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Pojo-config.xml
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Pojo-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties
- copied unchanged from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/webwork.properties
struts/sandbox/trunk/action2/apps/cookbook/src/java/xwork.xml
- copied, changed from r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/xwork.xml
Removed:
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/ActionTag-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Hello-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Home-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Pojo-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Select-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/Simple-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/webwork.properties
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/xwork.xml
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/Pojo/Input.jsp
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java?rev=386676r1=386675r2=386676view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
(original)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
Fri Mar 17 09:50:38 2006
@@ -10,4 +10,11 @@
public Object getModel() {
return directoryEntry;
}
+
+public String method1() {
+
+directoryEntry.setHours(new Integer(37));
+
+return SUCCESS;
+}
}
Copied: struts/sandbox/trunk/action2/apps/cookbook/src/java/xwork.xml (from
r386674,
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/xwork.xml)
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/java/xwork.xml?p2=struts/sandbox/trunk/action2/apps/cookbook/src/java/xwork.xmlp1=struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/xwork.xmlr1=386674r2=386676rev=386676view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/WEB-INF/classes/xwork.xml
(original)
+++ struts/sandbox/trunk/action2/apps/cookbook/src/java/xwork.xml Fri Mar 17
09:50:38 2006
@@ -4,16 +4,16 @@
include file=webwork-default.xml/
-include file=Home-config.xml/
+include file=cookbook2/Home-config.xml/
-include file=Hello-config.xml/
+include file=cookbook2/Hello-config.xml/
-include file=Simple-config.xml/
+include file=cookbook2/Simple-config.xml/
-include file=Pojo-config.xml/
+include file=cookbook2/pojo/Pojo-config.xml/
-include file=Select-config.xml/
+include file=cookbook2/Select-config.xml/
-include file=ActionTag-config.xml /
+include file=cookbook2/actiontag/ActionTag-config.xml /
/xwork
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/Pojo/Input.jsp
URL:
svn commit: r386680 - in /struts/sandbox/trunk/action2: ./ apps/cookbook/src/java/cookbook2/pojo/ apps/cookbook/src/webapp/pages/ActionTag/ apps/cookbook/src/webapp/pages/Pojo/ apps/cookbook/src/webap
Author: husted
Date: Fri Mar 17 10:05:00 2006
New Revision: 386680
URL: http://svn.apache.org/viewcvs?rev=386680view=rev
Log:
Action2 Apps
* Change forms to use POST method.
* Remove some play-test code.
Added:
struts/sandbox/trunk/action2/PRACTICES.txt (with props)
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/Input.jsp
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/Pojo/Input.jsp
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/Select/Input.jsp
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/Simple/Input.jsp
Added: struts/sandbox/trunk/action2/PRACTICES.txt
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/PRACTICES.txt?rev=386680view=auto
==
--- struts/sandbox/trunk/action2/PRACTICES.txt (added)
+++ struts/sandbox/trunk/action2/PRACTICES.txt Fri Mar 17 10:05:00 2006
@@ -0,0 +1,39 @@
+Action2 Apps Best Practices
+
+* Link only to actions, never to server pages or templates
+
+* Do not expose the action extension in your tags. Use the action parameter
instead.
+
+* Use namespaces to organize your application into logical modules or units
of work.
+
+* Place each namespace into it's own Xwork config.
+ ** Try to keep the Actions classes for the namespace in a common package.
+ ** Store the Xwork configuration for that namespace with the Actions.
+ ** If you are using JSPs, try to name the JSP folder after the Action package.
+ ** If you using templates, bundle the templates with the Actions.
+ ** Remember, if the namespace needs to change, you do not need to change
packages or JSP folders, if you don't want to.
+
+* Within a namespace, resuse names for common concepts. If each namespace has
an entry page, use the same action name in each namespace. For example, each
namespace in the Cookbook has an Open action.
+
+* Unit test actions before trying them in a web application.
+ ** Since JUnit is integrated in most IDEs now, there is no excuse.
+
+* Consider using WebCanoo, HtmlUnit, or HttpUnit to test navigation, as the
application is being developed.
+
+* Use SiteMesh, or the equivalent, to separate application chrome from the
core utility of the server pages.
+
+* Specify the POST method for forums, unless there is a reason to use the
default GET method.
+
+* If an image, or other swatch of markup, is being used by multiple pages,
remove it to its own server page and include it where necessary.
+ ** Better yet, encapsulate the markup in its own UI tag.
+
+* Extend the UI tags as needed.
+
+* Consider using the message resources for page titles, control labels, and so
forth, even if the application is not being localized.
+ ** It is often useful to seperate the concern of what message to display form
the concern of where to display it.
+
+* Use the XML framework to validate input.
+
+* Do not embed business logic in action classes.
+ ** Remove business logic to a business facade that the actions can call.
(Spring is an excellent way to build a business facade.)
+ ** Actions are a necessary evil. Every line of code in an Action is guilty
until proven innocent. Ideally, there should be one line of code that calls the
business facade, and every other line of a code in an action should be bound to
the framework.
Propchange: struts/sandbox/trunk/action2/PRACTICES.txt
--
svn:eol-style = native
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java?rev=386680r1=386679r2=386680view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
(original)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/pojo/Result.java
Fri Mar 17 10:05:00 2006
@@ -11,10 +11,4 @@
return directoryEntry;
}
-public String method1() {
-
-directoryEntry.setHours(new Integer(37));
-
-return SUCCESS;
-}
}
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/Input.jsp
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/Input.jsp?rev=386680r1=386679r2=386680view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/Input.jsp
(original)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/Input.jsp
Fri Mar 17 10:05:00 2006
@@ -17,7 +17,7 @@
Accordingly, each control could be re-used on any number of pages.
/p
-ww:form
+ww:form method=POST
[action] Maven groupId and svn repo structure
We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action] Maven groupId and svn repo structure
On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: Any thoughts on grouping the Action 1 related modules together in some way? Hmmm, that's going to depend on what you mean by Action 1 related modules. Would Scripting and Flow fall into that category, or just Action, Apps, EL, Extras, and Taglib? What about Tiles when it comes up from the sandbox? It looks like that can be shared by all three frameworks, Action, Action2, and Shale. And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) My suggestion would be to treat the codebase the same way we are handling Shale, except the root package might be something like org.apache.action2 or org.apache.struts.action2. In the sandbox, I started an action2 folder and added apps under that. I've got a good start on an Action 2 Cookbook, and an Action 2 Mailreader is next. Here I'm using package names like cookbook2 and mailreader2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork 2 Incubation Status
On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: 1. We have an official Incubator status page at http://incubator.apache.org/projects/webwork2.html For future reference, there is also a link to this on the Apache Struts home page, under Incubating ... And, hey, good work so far, Don :) The WebWork 2 team has been working hard this entire time I can testify to that. One day I asked if it would be a good idea to use a WebWork Result to display the sourcecode in an application cookbook. The next day, Toby Jee had it written, tested, and checked in! 3. Example applications - Ted has been working hard on migrating popular Action 1 applications such as the Mailreader and the iBATIS JPetstore application over to Action 2. This will provide developers an example of Action 2 best practices and a practical example to help them migrate their Action 1 knowledge. Yes, there is already a starter Cookbook checked into the sandbox, and I'm starting on the MailReader this afternoon. I've time set aside to work on the applications every week day now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib What is the difference between el and taglib besides el support? Would not it be more logical to have action/trunk/taglib and action/trunk/taglib-el ? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r386694 - in /struts/sandbox/trunk/action2/apps/cookbook/src: java/ java/cookbook2/actiontag/ test/ test/cookbook2/ test/cookbook2/actiontag/ webapp/pages/ActionTag/
Author: husted
Date: Fri Mar 17 11:15:26 2006
New Revision: 386694
URL: http://svn.apache.org/viewcvs?rev=386694view=rev
Log:
Action2 Apps
* Add a JUnit test for the Languages action (that populates a list box).
Added:
struts/sandbox/trunk/action2/apps/cookbook/src/test/
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java
(with props)
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml
struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/index.jsp
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml?rev=386694r1=386693r2=386694view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml
(original)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/java/cookbook2/actiontag/ActionTag-config.xml
Fri Mar 17 11:15:26 2006
@@ -45,6 +45,10 @@
result
type=plaintext/WEB-INF/src/java/cookbook2/actiontag/Languages.java/result
/action
+action name=View-Test-Languages
+result
type=plaintext/WEB-INF/src/test/cookbook2/actiontag/LanguagesTest.java/result
+/action
+
action name=View-Config
result
type=plaintext/WEB-INF/classes/ActionTag-config.xml/result
/action
Modified: struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties?rev=386694r1=386693r2=386694view=diff
==
--- struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties
(original)
+++ struts/sandbox/trunk/action2/apps/cookbook/src/java/webwork.properties Fri
Mar 17 11:15:26 2006
@@ -1,4 +1,3 @@
webwork.objectFactory = spring
webwork.devMode = true
-webwork.tag.altSyntax = true
webwork.action.extension = do,jspa
Added:
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java?rev=386694view=auto
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java
(added)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java
Fri Mar 17 11:15:26 2006
@@ -0,0 +1,34 @@
+package cookbook2.actiontag;
+
+import junit.framework.TestCase;
+import java.util.List;
+
+import cookbook2.Select;
+
+public class LanguagesTest extends TestCase {
+
+private Languages action;
+
+public void setUp() {
+
+action = new Languages();
+
+}
+
+public void testContents() throws Exception {
+
+List list = action.getFavoriteLanguages();
+assertNotNull(List is null!,list);
+assertTrue(List is not empty,list.size()==0);
+
+action.execute();
+
+List list2 = action.getFavoriteLanguages();
+assertNotNull(List is null!,list2);
+assertTrue(List is empty!,list.size()0);
+Select.Language entry = (Select.Language) list.get(0);
+assertNotNull(Entry is null,entry);
+assertTrue(Entry is empty,entry.getDescription().length()0);
+}
+
+}
Propchange:
struts/sandbox/trunk/action2/apps/cookbook/src/test/cookbook2/actiontag/LanguagesTest.java
--
svn:eol-style = native
Modified:
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/index.jsp
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/index.jsp?rev=386694r1=386693r2=386694view=diff
==
---
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/index.jsp
(original)
+++
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/pages/ActionTag/index.jsp
Fri Mar 17 11:15:26 2006
@@ -31,6 +31,13 @@
a href=ww:url action=View-Action-Languages/Languages.java/a
/li/ul
+
+h2Tests/h2
+ulli
+a href=ww:url action=View-Test-Languages/LanguagesTest.java/a
+/li/ul
+
+
h2Configuration files/h2
ulli
a href=ww:url action=View-Config/ActionTag-config.xml/a
-
To unsubscribe, e-mail:
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On Fri, March 17, 2006 1:48 pm, Don Brown said: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. Just to see if I understand... There would be a single Action entity, that contains all of these? If you download Action you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity Action as opposed to Struts. Is that correct? If so, definite +1 from me. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. If I'm understanding your proposal, it would be a course change, but I think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. I think this proposal would eliminate a lot of potential confusion with version dependencies, which I think is clearly a good thing. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. I wouldn't consider it a step backward actually... an idea was proposed... it was implemented... there is now some thought that maybe it didn't work out quite as hoped... now a decision is made to do something different which just happens to be what was done before the decision. This is just good, flexible, thoughtful decision-making and leadership. I can only speak as a member of the developer community... I thought the separate release cycles, while not without merit, had the potential to be confusing and make things more difficult on developers, and maybe too the committers. Therefore, I would support this proposal, just as an interested third-party. Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
If we're going to consolidate, why not go whole hog and have a single artifact? I agree that past experience and the future of action2 suggest that there's not going to be a lot of activity in various subprojects independent of an individual release. Joe At 10:48 AM -0800 3/17/06, Don Brown wrote: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Michael Jouravlev wrote: On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib What is the difference between el and taglib besides el support? Would not it be more logical to have action/trunk/taglib and action/trunk/taglib-el ? Well, yes, I suppose that name would be more accurate, and we could switch if this proposal was accepted. Don Michael. - 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Joe Germuska wrote: If we're going to consolidate, why not go whole hog and have a single artifact? I still see value in the extensions having their own artifacts. For one, it makes it easier to grok for new folks, and in cases like taglib and el, they can't be merged. I see it working similarly to how Spring manages its components. Don I agree that past experience and the future of action2 suggest that there's not going to be a lot of activity in various subprojects independent of an individual release. Joe At 10:48 AM -0800 3/17/06, Don Brown wrote: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Frank W. Zammetti wrote: On Fri, March 17, 2006 1:48 pm, Don Brown said: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. Just to see if I understand... There would be a single Action entity, that contains all of these? If you download Action you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity Action as opposed to Struts. Is that correct? If so, definite +1 from me. Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1 jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the version number of each component matching up. think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. The subproject split was way before the WW merger, and IIRC, I was the one that did the original SVN moving arounds at ApacheCon two years ago. The emergence of Action 2 changes things completely, and IMO, the reasons we split as we did aren't valid anymore. I don't see it as much as a reversal, but a new evolution. We are still keeping many of the same subprojects, just consolidating the Action 1-specific ones ahead of the Action 2 start. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork 2 Incubation Status
Good work Don! ./alex -- .w( the_mindstorm )p. On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: This is the status of the WebWork 2 Incubation: 1. We have an official Incubator status page at http://incubator.apache.org/projects/webwork2.html 2. March 22 is the scheduled date for the WebWork 2.2.2 release, and subsequent SVN cutover to the Apache Incubator repository. 3. The JIRA cutover is also scheduled for March 22, however, it is less certain as we are dependent on the time of Jeff Turner, the Apache JIRA guy. 4. All but Toby Jee have sent in their CLA's and have been given an Apache account and SVN access. 5. We are still gathering CLA's from non-active WebWork 2 developers and will be throughout Incubation The WebWork 2 team has been working hard this entire time so while it may seem like Action 2 isn't coming along, it has been quite rapidly. The WebWork 2 commits will be sent to this list, so that everyone may be informed of its progress and encouraged to jump in and help the effort. At this time, we are planning three migration paths for Action 1 users: 1. Dual processors, shared resources - Run Action 1 and Action 2 servlets/filters side-by-side sharing resources like messages and validations, allowing a developer to migrate a module or so at a time. 2. Migration tools - These tools would help a developer to migrate their entire application to Action 2 using XSLT stylesheets, an integration library to use existing ActionForms unmodified on Action 2, and possibly an entire port of the Action 1 processing chain to Action 2. 3. Example applications - Ted has been working hard on migrating popular Action 1 applications such as the Mailreader and the iBATIS JPetstore application over to Action 2. This will provide developers an example of Action 2 best practices and a practical example to help them migrate their Action 1 knowledge. Again, welcome WebWork 2 development team and community, and lets try to get this Action 2 out the door ASAP, but no sooner ;) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r386730 - in /struts/sandbox/trunk/action2/apps/mailreader: ./ META-INF/ src/ src/java/ src/java/mailreader2/ src/test/ src/webapp/ src/webapp/WEB-INF/ src/webapp/css/ src/webapp/pages/
Author: husted
Date: Fri Mar 17 13:45:23 2006
New Revision: 386730
URL: http://svn.apache.org/viewcvs?rev=386730view=rev
Log:
Action2 Apps
* Initial checkin of Action2 MailReader with a starter Welcome page.
Added:
struts/sandbox/trunk/action2/apps/mailreader/
struts/sandbox/trunk/action2/apps/mailreader/META-INF/
struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/
struts/sandbox/trunk/action2/apps/mailreader/src/java/
struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/
struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/resources_ja.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/resources_ru.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/webwork.properties
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/test/
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/applicationContext.xml
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/css/
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/css/mailreader.css
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/index.html (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/struts-power.gif
(with props)
Added: struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml?rev=386730view=auto
==
--- struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml (added)
+++ struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml Fri Mar
17 13:45:23 2006
@@ -0,0 +1,3 @@
+?xml version=1.0 encoding=UTF-8?
+Context path=/
+/Context
Propchange: struts/sandbox/trunk/action2/apps/mailreader/META-INF/context.xml
--
svn:eol-style = native
Added: struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java?rev=386730view=auto
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java (added)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java Fri Mar 17
13:45:23 2006
@@ -0,0 +1,18 @@
+package blank2;
+
+import com.opensymphony.xwork.ActionSupport;
+
+/**
+ * Utilize the SUCCESS result.
+ */
+public class Home extends ActionSupport {
+
+/**
+ * Return the default SUCCESS token.
+ *
+ * @return [EMAIL PROTECTED] #SUCCESS}
+ */
+public String execute() throws Exception {
+return SUCCESS;
+}
+}
Propchange: struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java
--
svn:eol-style = native
Added:
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties?rev=386730view=auto
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
(added)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
Fri Mar 17 13:45:23 2006
@@ -0,0 +1,3 @@
+prompt.password=Enter your Password here ==
+struts.logo.path=/struts-power.gif
+struts.logo.alt=Powered by Struts
Propchange:
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
--
svn:eol-style = native
Added:
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties?rev=386730view=auto
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Don Brown wrote: Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1 jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the version number of each component matching up. Great! Yes, I think just simply not having to worry about the versions is worth it. Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Servlet mapping in a Struts app?
I must be misunderstanding something about the way servlet mapping works with my Struts application in Tomcat. I have two servlet mappings in web.xml: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-nameaction/servlet-name url-pattern/API/*/url-pattern /servlet-mapping The first is for my action handlers. The second is recently added, and represents a collection of third party API functions that I've implemented (also as action handlers). However, my base application is now doing the following. When I hit https://localhost/MyApp/login.jsp; for my main app, the following html:form tag in login.jsp: html:form action=Login.do focus=userId Gets turned into: form name=loginForm method=post action=/MyApp/API/Login I'm confused as to why it's adding the /API to the form action, but it's got to be related to the new servlet-mapping. My struts-config.xml looks like the following, and there's not mention of API: action path=/Login type=com.vtgroup.controller.LoginAction name=loginForm scope=request validate=false input=/login.jsp /action Please enlighten me, as I feel stupid about this, but can't figure it out. Thanks. Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet mapping in a Struts app?
Struts doesn't support multiple servlet mappings, which is probably why you are seeing some strange results. Don Jay Burgess wrote: I must be misunderstanding something about the way servlet mapping works with my Struts application in Tomcat. I have two servlet mappings in web.xml: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-nameaction/servlet-name url-pattern/API/*/url-pattern /servlet-mapping The first is for my action handlers. The second is recently added, and represents a collection of third party API functions that I've implemented (also as action handlers). However, my base application is now doing the following. When I hit https://localhost/MyApp/login.jsp; for my main app, the following html:form tag in login.jsp: html:form action=Login.do focus=userId Gets turned into: form name=loginForm method=post action=/MyApp/API/Login I'm confused as to why it's adding the /API to the form action, but it's got to be related to the new servlet-mapping. My struts-config.xml looks like the following, and there's not mention of API: action path=/Login type=com.vtgroup.controller.LoginAction name=loginForm scope=request validate=false input=/login.jsp /action Please enlighten me, as I feel stupid about this, but can't figure it out. Thanks. Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ - 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: Servlet mapping in a Struts app?
That probably explains it then. :) I'm still a little confused, though, as I thought that the mappings were directives for the container (Tomcat in this case), but obviously Struts also needs to get it from somewhere to build the form action URL, so this must be where it's getting messed up. I'm going to play around some more this weekend, but it may be that I end up having to call my API function .do's to get it to work. Thanks for the reply. Jay -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 4:18 PM To: Struts Developers List Subject: Re: Servlet mapping in a Struts app? Struts doesn't support multiple servlet mappings, which is probably why you are seeing some strange results. Don Jay Burgess wrote: I must be misunderstanding something about the way servlet mapping works with my Struts application in Tomcat. I have two servlet mappings in web.xml: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-nameaction/servlet-name url-pattern/API/*/url-pattern /servlet-mapping The first is for my action handlers. The second is recently added, and represents a collection of third party API functions that I've implemented (also as action handlers). However, my base application is now doing the following. When I hit https://localhost/MyApp/login.jsp; for my main app, the following html:form tag in login.jsp: html:form action=Login.do focus=userId Gets turned into: form name=loginForm method=post action=/MyApp/API/Login I'm confused as to why it's adding the /API to the form action, but it's got to be related to the new servlet-mapping. My struts-config.xml looks like the following, and there's not mention of API: action path=/Login type=com.vtgroup.controller.LoginAction name=loginForm scope=request validate=false input=/login.jsp /action Please enlighten me, as I feel stupid about this, but can't figure it out. Thanks. Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet mapping in a Struts app?
First, let me say SORRY! for using the dev@ list. I intended this to go to user@, but must have copied the wrong address when I started this thread. Second, following on from my last email, it looks like if I reverse the order of the servlet-mappings in web.xml, things start to work. Maybe Struts is just storing the last mapping it finds at startup time, as opposed to using the actual mapping at runtime? (Glancing at addServletMapping() in ActionServlet.java makes me think this too.) So, reversing the order solves the problem, in case anyone else tries something similar. Jay -Original Message- From: Jay Burgess [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 4:25 PM To: dev@struts.apache.org Subject: RE: Servlet mapping in a Struts app? That probably explains it then. :) I'm still a little confused, though, as I thought that the mappings were directives for the container (Tomcat in this case), but obviously Struts also needs to get it from somewhere to build the form action URL, so this must be where it's getting messed up. I'm going to play around some more this weekend, but it may be that I end up having to call my API function .do's to get it to work. Thanks for the reply. Jay -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 4:18 PM To: Struts Developers List Subject: Re: Servlet mapping in a Struts app? Struts doesn't support multiple servlet mappings, which is probably why you are seeing some strange results. Don Jay Burgess wrote: I must be misunderstanding something about the way servlet mapping works with my Struts application in Tomcat. I have two servlet mappings in web.xml: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-nameaction/servlet-name url-pattern/API/*/url-pattern /servlet-mapping The first is for my action handlers. The second is recently added, and represents a collection of third party API functions that I've implemented (also as action handlers). However, my base application is now doing the following. When I hit https://localhost/MyApp/login.jsp; for my main app, the following html:form tag in login.jsp: html:form action=Login.do focus=userId Gets turned into: form name=loginForm method=post action=/MyApp/API/Login I'm confused as to why it's adding the /API to the form action, but it's got to be related to the new servlet-mapping. My struts-config.xml looks like the following, and there's not mention of API: action path=/Login type=com.vtgroup.controller.LoginAction name=loginForm scope=request validate=false input=/login.jsp /action Please enlighten me, as I feel stupid about this, but can't figure it out. Thanks. Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ - 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 1.2.9 Quality
On 3/17/06, Ted Husted [EMAIL PROTECTED] wrote: On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: The difference is that Spring is commercial open source. Here it needs a volunteer willing to do it and the problem with that if eat our own dog food how likely is it there'll be a volunteer wanting to back port? Following up on something Niall said elsewhere, the trick to open source is to concentrate on scratching your own itch. If there's a feature that *you* want implemented for *your* application, go ahead and implement it, and then try to share the wealth. Worst case, you've got a feature that you needed. Ditto for patches and fixes. Worse case, you've patched your copy of the framework so that it works better for you. Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. I have to disagree. There are more colours than black and white. I've played devils advocate for Frank in another thread, now it's your turn :-) Consider following example, which took place approx. 6 month ago: Someone (lets call him X) is using struts in his corporate environment. X and/or X's company develops some extensions/new features/whatever to the struts distro. The features are actually used and are actually running and being tested in production and so on. One day X and/or X's company decides: Ok, we are using an OpenSource project, and we benefit from this project, it's time to give something back to the community. X 'comes' to the StrutsDevList and says: Ok we developed a new feature on top of the project (or inside the project) and we'd like to give it back to the community to honour communities work and especially the work of the commiters. What would be the answer? Right: not interested. The above example should illustrate how the open source projects are ment to work. They aren't working that way. You will understand that this creates a lot of frustration upon the volunteers and I greatly honour all the volunteers, who managed to contribute and give something back to the community despite the commiters effort to prevent it. /devils advocate speech -Ted. Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.9 Quality
On 3/17/06, Leon Rosenberg [EMAIL PROTECTED] wrote: On 3/17/06, Ted Husted [EMAIL PROTECTED] wrote: On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: The difference is that Spring is commercial open source. Here it needs a volunteer willing to do it and the problem with that if eat our own dog food how likely is it there'll be a volunteer wanting to back port? Following up on something Niall said elsewhere, the trick to open source is to concentrate on scratching your own itch. If there's a feature that *you* want implemented for *your* application, go ahead and implement it, and then try to share the wealth. Worst case, you've got a feature that you needed. Ditto for patches and fixes. Worse case, you've patched your copy of the framework so that it works better for you. Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. I have to disagree. There are more colours than black and white. I've played devils advocate for Frank in another thread, now it's your turn :-) Consider following example, which took place approx. 6 month ago: Someone (lets call him X) is using struts in his corporate environment. X and/or X's company develops some extensions/new features/whatever to the struts distro. The features are actually used and are actually running and being tested in production and so on. One day X and/or X's company decides: Ok, we are using an OpenSource project, and we benefit from this project, it's time to give something back to the community. X 'comes' to the StrutsDevList and says: Ok we developed a new feature on top of the project (or inside the project) and we'd like to give it back to the community to honour communities work and especially the work of the commiters. What would be the answer? Right: not interested. The above example should illustrate how the open source projects are ment to work. Sorry, but that is incorrect. Contributions to ASF projects, at least, are not simply accepted because they were offered. There are several factors that need to be taken into account. To give just two: (1) Does the contribution fit with the direction of the project as determined by the committers; (2) Are there committers willing to step up not just to add the contribution to the source code, but to vet it first, and be responsible for, and maintain, that new code over time. If we had accepted every contribution that had ever been offered to Struts over the last 6 years, the end result would be a complete shambles by now. (IMHO, of course.) Yes, I understand that it can be frustrating when someone's pet awesome enhancement isn't instantly adopted, but understand that there's a lot more to it than just checking it in and keeping going. They aren't working that way. You will understand that this creates a lot of frustration upon the volunteers and I greatly honour all the volunteers, who managed to contribute and give something back to the community despite the commiters effort to prevent it. If you think we expend effort to prevent giving back, then you have a screw loose. ;-p -- Martin Cooper /devils advocate speech -Ted. Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r386789 - in /struts/sandbox/trunk/action2/apps: cookbook/src/webapp/ mailreader/src/java/ mailreader/src/java/mailreader2/ mailreader/src/webapp/pages/
Author: husted
Date: Fri Mar 17 18:01:21 2006
New Revision: 386789
URL: http://svn.apache.org/viewcvs?rev=386789view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
Added:
struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml (with
props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Logon-validation
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Logon.java
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Footer.jsp
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/MainMenu.jsp
(with props)
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp
(with props)
Removed:
struts/sandbox/trunk/action2/apps/mailreader/src/java/Home.java
Modified:
struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp
Added: struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html?rev=386789view=auto
==
--- struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html (added)
+++ struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html Fri Mar 17
18:01:21 2006
@@ -0,0 +1,9 @@
+!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
+html
+head
+META HTTP-EQUIV=Refresh CONTENT=0;URL=Home.jsp
+/head
+body
+pLoading .../p
+/body
+/html
Propchange: struts/sandbox/trunk/action2/apps/cookbook/src/webapp/index.html
--
svn:eol-style = native
Added: struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml?rev=386789view=auto
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml (added)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml Fri Mar
17 18:01:21 2006
@@ -0,0 +1,12 @@
+?xml version='1.0'?
+database
+user username=user fromAddress=[EMAIL PROTECTED]
+ fullName=John Q. User password=pass
+subscription host=mail.hotmail.com autoConnect=false
+ password=bar type=pop3 username=user1234
+/subscription
+subscription host=mail.yahoo.com autoConnect=false password=foo
+ type=imap username=jquser
+/subscription
+/user
+/database
Propchange: struts/sandbox/trunk/action2/apps/mailreader/src/java/database.xml
--
svn:eol-style = native
Added:
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
URL:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java?rev=386789view=auto
==
---
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
(added)
+++
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
Fri Mar 17 18:01:21 2006
@@ -0,0 +1,235 @@
+/*
+ * $Id: Constants.java 360442 2005-12-31 20:10:04Z husted $
+ *
+ * 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 mailreader2;
+
+/**
+ * p
+ * Manifest constants for the MailReader application.
+ * /p
+ *
+ * @version $Rev: 360442 $ $Date: 2005-12-31 15:10:04 -0500 (Sat, 31 Dec 2005)
$
+ */
+
+public final class Constants {
+
+// --- Tokens
+
+/**
+ * p
+ * The token representing a create task.
+ * /p
+ */
+public static final String CREATE = Create;
Re: [VOTE] Struts 1.2.9 Quality
On 3/18/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/17/06, Leon Rosenberg [EMAIL PROTECTED] wrote: On 3/17/06, Ted Husted [EMAIL PROTECTED] wrote: On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: The difference is that Spring is commercial open source. Here it needs a volunteer willing to do it and the problem with that if eat our own dog food how likely is it there'll be a volunteer wanting to back port? Following up on something Niall said elsewhere, the trick to open source is to concentrate on scratching your own itch. If there's a feature that *you* want implemented for *your* application, go ahead and implement it, and then try to share the wealth. Worst case, you've got a feature that you needed. Ditto for patches and fixes. Worse case, you've patched your copy of the framework so that it works better for you. Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution, then the first thing I think is that this person is volunteering for the wrong reasons, and, if so, it would be better if they didn't volunteer to do the work. I have to disagree. There are more colours than black and white. I've played devils advocate for Frank in another thread, now it's your turn :-) Consider following example, which took place approx. 6 month ago: Someone (lets call him X) is using struts in his corporate environment. X and/or X's company develops some extensions/new features/whatever to the struts distro. The features are actually used and are actually running and being tested in production and so on. One day X and/or X's company decides: Ok, we are using an OpenSource project, and we benefit from this project, it's time to give something back to the community. X 'comes' to the StrutsDevList and says: Ok we developed a new feature on top of the project (or inside the project) and we'd like to give it back to the community to honour communities work and especially the work of the commiters. What would be the answer? Right: not interested. The above example should illustrate how the open source projects are ment to work. Sorry, but that is incorrect. Contributions to ASF projects, at least, are not simply accepted because they were offered. There are several factors that need to be taken into account. To give just two: (1) Does the contribution fit with the direction of the project as determined by the committers; (2) Are there committers willing to step up not just to add the contribution to the source code, but to vet it first, and be responsible for, and maintain, that new code over time. If we had accepted every contribution that had ever been offered to Struts over the last 6 years, the end result would be a complete shambles by now. (IMHO, of course.) Yes, I understand that it can be frustrating when someone's pet awesome enhancement isn't instantly adopted, but understand that there's a lot more to it than just checking it in and keeping going. Martin, my reply was about Teds Anytime anyone says something like I don't want to do this work unless it's going to be accepted to the distribution ... and not about the accept rules for code. I just wanted to show, that there are usecases where the above preamble is perfectly valid. It just goes the other way around: I already have the fix/patch/enhancement IF YOU WANT IT I volunteer to backport it. The reasons why is something accepted and why not is another topic. They aren't working that way. You will understand that this creates a lot of frustration upon the volunteers and I greatly honour all the volunteers, who managed to contribute and give something back to the community despite the commiters effort to prevent it. If you think we expend effort to prevent giving back, then you have a screw loose. ;-p Year, and you are Miko, the shiny paladin from the Azure City... :-) http://www.giantitp.com/cgi-bin/GiantITP/ootscript -- Martin Cooper Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
