RE: 1.2.0 uploaded - Take 2
I'm assuming it's at the same location since the el is in the download (the file dates from Apache are the same as last nights upload). All my tests pass! Matt -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 12:25 AM To: Struts Developers List Subject: 1.2.0 uploaded - Take 2 I've just finished uploading a new build that includes Struts-EL. (And none too soon, given the huge thunderstorm going on here right now...) It's in the same location as before, listed below. Again, I'd appreciate it if someone could verify the integrity of the files, and let me know if they're OK. Hopefully, this one will be OK and I can go ahead and announce it to both lists. -- Martin Cooper On Wed, 25 Feb 2004, Martin Cooper wrote: On Sun, 22 Feb 2004, Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. The release is now, finally, on minotaur. You can find it here: http://www.apache.org/~martinc/struts/ Before I send out an announcement message, I would really appreciate it if someone could verify the integrity of the files (e.g. by checking the sigs against the files themselves), since I had so much trouble uploading them. random-spout As a result of this debacle, I have a new-found intense dislike of my ISP and a new-found respect for Linux. My ISP supports only Windows, and has been unable to resolve my problems in uploading large files using Windows, even though it is abundantly clear that the problem is on their end. Eventually, I solved the problem by transferring the files to a separate box that runs SuSE Linux (Thanks, Arron!), and uploading the files from there using scp. My ISP does not support Linux at all, yet scp on Linux recovered from the network stalls that caused Windows to lock up. So it seems that networking is more reliable, with my ISP, using unsupported operating systems than using supported operating systems... /random-spout -- Martin Cooper 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts-examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper On Sun, 22 Feb 2004, Martin Cooper wrote: Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is TagUtils instance final?
I don't understand why the instance of TagUtils has been made final: private static final TagUtils instance = new TagUtils(); Isn't the logic behind having an 'instance' of TagUtils so that if someone want to change an aspect of TagUtils behaviour they can extend it and override a particular method? Otherwise why not just have a bunch of static methods in TagUtils? Does anyone have opinions on changing this so that TagUtils implementation could be customized? Niall
Tree is open
It's probably obvious by now, but just wanted to confirm that the CVS tree is no longer frozen. Now we can get those pending commits dealt with. ;-) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts build.xml
martinc 2004/02/26 22:26:42 Modified:.build.xml Log: Update build version to 1.2.1-dev. Revision ChangesPath 1.129 +1 -1 jakarta-struts/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-struts/build.xml,v retrieving revision 1.128 retrieving revision 1.129 diff -u -r1.128 -r1.129 --- build.xml 22 Feb 2004 10:03:51 - 1.128 +++ build.xml 27 Feb 2004 06:26:42 - 1.129 @@ -148,7 +148,7 @@ property name=project.name value=jakarta-struts/ !-- Version of the project -- -property name=project.version value=1.2.0/ +property name=project.version value=1.2.1-dev/ !-- == Derived Properties -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is TagUtils instance final?
--- Niall Pemberton [EMAIL PROTECTED] wrote: I don't understand why the instance of TagUtils has been made final: private static final TagUtils instance = new TagUtils(); It's simply following the Singleton pattern. I have no problems with changing this to allow clients to instantiate a TagUtils instance directly. David Isn't the logic behind having an 'instance' of TagUtils so that if someone want to change an aspect of TagUtils behaviour they can extend it and override a particular method? Otherwise why not just have a bunch of static methods in TagUtils? Does anyone have opinions on changing this so that TagUtils implementation could be customized? Niall __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Committers, please read
Per Geir's message, below, any committer without a CLA on file by March 1st will lose their commit privileges. There are several Struts committers who are listed as not having CLAs on file. Many of those people have not been active here for quite some time, but I wanted to be sure everyone has a chance to retain their commit privileges, should they so desire. If you're a committer, and you're not sure if you have a CLA on file, please read the message below, and follow up if necessary. -- Martin Cooper -- Forwarded message -- Date: Mon, 23 Feb 2004 18:25:27 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: CLAs : Deadline is March 1, 2004 to avoid suspension of commit privs Jakarta Committers, The March 1 CLA deadline for CLAs is approaching quickly. As you are aware, all committers working on Apache Software Foundation projects are required to have a CLA filed with the ASF. This document clearly defines the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. Every committer is responsible for ensuring a CLA is on file with the ASF by March 1, 2004. Any committer that does not have a CLA on file will have their committer privs suspended. To check to see if one is on file for you, please look here : http://www.apache.org/~jim/committers.html If your name is *not* in italics, there is no CLA on file. f you are not listed as having a CLA on file, read about it and get one : http://www.apache.org/licenses/#clas and follow the instructions. It's really easy. Please direct all questions and problems to [EMAIL PROTECTED] or the public list if you don't mind public discussion of your situation. We will do what we can to help resolve any issues that arise. Silence on this issue isn't an option. The ASF is working to tie up any IP-related loose-ends, and this is an important one - they will suspend commit privs. Thanks geir, writing on behalf of the Jakarta PMC -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27236] - Form population automatically assign default value when parsing error occurs.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27236 Form population automatically assign default value when parsing error occurs. --- Additional Comments From [EMAIL PROTECTED] 2004-02-26 20:00 --- This is not a bug, because you should have only strings in your actionforms. Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el build.xml
martinc 2004/02/26 22:32:22 Modified:contrib/struts-el build.xml Log: Document the jstl.tld.dir property, required to build Struts-EL. Revision ChangesPath 1.21 +3 -0 jakarta-struts/contrib/struts-el/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- build.xml 10 Feb 2004 16:35:10 - 1.20 +++ build.xml 27 Feb 2004 06:32:22 - 1.21 @@ -38,6 +38,9 @@ jstl-standard.jar The path to the JSTL 1.0 standard jar file. +jstl.tld.dir The path to the directory containing the + TLD files for JSTL 1.0. + commons-beanutils.jar The path to the JAR file of the Jakarta Commons BeanUtils package (version 1.0 or later). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util LocalStrings_ja.properties
rleland 2004/02/26 16:33:24
Modified:contrib/struts-faces/src/example/org/apache/struts/webapp/example
ApplicationResources_ja.properties
contrib/struts-faces/src/example2/org/apache/struts/webapp/example2
ApplicationResources_ja.properties
src/example/org/apache/struts/webapp/example
ApplicationResources_ja.properties
src/examples/org/apache/struts/webapp/exercise
MessageResources.properties
src/examples/org/apache/struts/webapp/validator
MessageResources_ja.properties
src/share/org/apache/struts/action
ActionResources_ja.properties
LocalStrings_ja.properties
src/share/org/apache/struts/actions
LocalStrings_ja.properties
src/share/org/apache/struts/taglib/bean
LocalStrings_ja.properties
src/share/org/apache/struts/taglib/html
LocalStrings_ja.properties
src/share/org/apache/struts/taglib/logic
LocalStrings_ja.properties
src/share/org/apache/struts/util LocalStrings_ja.properties
Log:
Bug 27195, report patch provided by Yoshinori Ashizawa at jajakarta.org
To update Japanese language resources.
Revision ChangesPath
1.2 +60 -31
jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/ApplicationResources_ja.properties
Index: ApplicationResources_ja.properties
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/ApplicationResources_ja.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ApplicationResources_ja.properties7 Mar 2003 03:22:42 - 1.1
+++ ApplicationResources_ja.properties27 Feb 2004 00:33:23 - 1.2
@@ -2,26 +2,31 @@
button.confirm=\u78ba\u8a8d
button.reset=\u30ea\u30bb\u30c3\u30c8
button.save=\u4fdd\u5b58
-database.load= {0}
\u304b\u3089\u30c7\u30fc\u30bf\u30d9\u30fc\u30b9\u3092\u30ed\u30fc\u30c9\u3067\u304d\u307e\u305b\u3093\u3002
-error.database.missing=li\u30e6\u30fc\u30b6\u30c7\u30fc\u30bf\u30d9\u30fc\u30b9\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093\u3002\u30ed\u30b0\u30aa\u30f3\u306e\u8a8d\u8a3c\u304c\u51fa\u6765\u307e\u305b\u3093\u3002/li
-error.fromAddress.format=liFrom\u30a2\u30c9\u30ec\u30b9\u306e\u66f8\u5f0f\u304c\u6b63\u3057\u304f\u3042\u308a\u307e\u305b\u3093\u3002/li
-error.fromAddress.required=liFrom\u30a2\u30c9\u30ec\u30b9\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.fullName.required=li\u30d5\u30eb\u30cd\u30fc\u30e0\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.host.required=li\u30e1\u30fc\u30eb\u30b5\u30fc\u30d0\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.noSubscription=liNo Subscription bean in user session/li
-error.password.required=li\u30d1\u30b9\u30ef\u30fc\u30c9\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.password2.required=li\u30d1\u30b9\u30ef\u30fc\u30c9(\u78ba\u8a8d\u7528)\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.password.match=li\u30d1\u30b9\u30ef\u30fc\u30c9\u3068\u78ba\u8a8d\u7528\u30d1\u30b9\u30ef\u30fc\u30c9\u304c\u4e00\u81f4\u3057\u3066\u3044\u307e\u305b\u3093\u3002/li
-error.password.mismatch=li\u30e6\u30fc\u30b6\u540d\u307e\u305f\u306f\u30d1\u30b9\u30ef\u30fc\u30c9\u304c\u4e0d\u6b63\u3067\u3059\u3002\u518d\u5165\u529b\u3057\u3066\u304f\u3060\u3055\u3044\u3002/li
-error.replyToAddress.format=li\u8fd4\u4fe1\u30a2\u30c9\u30ec\u30b9\u306e\u66f8\u5f0f\u304c\u6b63\u3057\u304f\u3042\u308a\u307e\u305b\u3093\u3002/li
-error.transaction.token=li\u3053\u306e\u30d5\u30a9\u30fc\u30e0\u306e\u5185\u5bb9\u304c\u6b63\u3057\u304f\u306a\u3044\u305f\u3081\u9001\u4fe1\u3059\u308b\u3053\u3068\u304c\u51fa\u6765\u307e\u305b\u3093\u3002/li
-error.type.invalid=li\u30b5\u30fc\u30d0\u30bf\u30a4\u30d7\u306f 'imap' \u304b
'pop3'\u306e\u3069\u3061\u3089\u304b\u3067\u306a\u3051\u308c\u3070\u306a\u308a\u307e\u305b\u3093\u3002/li
-error.type.required=li\u30b5\u30fc\u30d0\u30bf\u30a4\u30d7\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.username.required=li\u30e6\u30fc\u30b6\u540d\u304c\u5fc5\u8981\u3067\u3059\u3002/li
-error.username.unique=li\u305d\u306e\u30e6\u30fc\u30b6\u540d\u306f\u65e2\u306b\u4f7f\u7528\u3055\u308c\u3066\u3044\u307e\u3059\u3002
\u5225\u306e\u30e6\u30fc\u30b6\u540d\u3092\u9078\u629e\u3057\u3066\u304f\u3060\u3055\u3044\u3002/li
+change.message=\u30D1\u30B9\u30EF\u30FC\u30C9\u306E\u6709\u52B9\u671F\u9650\u304C\u904E\u304E\u307E\u3057\u305F\u3002\u30B7\u30B9\u30C6\u30E0\u7BA1\u7406\u8005\u306B\u304A\u554F\u3044\u5408\u308F\u305B\u4E0B\u3055\u3044
+change.try=\u518D\u8A66\u884C
DO NOT REPLY [Bug 27195] - Japanese Message Resorces for NightlyBuild(Please adopt in Struts1.2!!)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27195. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27195 Japanese Message Resorces for NightlyBuild(Please adopt in Struts1.2!!) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-27 00:38 --- Fixed, and Thanks for the Patches. This should be in the Feb 27th nightly build This will essentially be equalivent to the 1.2.0 release, however it is currently built and packaged with the nightly builds of other packages. If you experience a problem then you might either rebuild struts yourself with the jars included from the 1.2.0 release or simply replace the nightly versions of the commons-* with the 1.2.0 version of the jars. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
automatically handle invalid input format
Currently, Struts recommends all fields of ActionForm be of type String. If you use other type (such as Date), and user inputs the value in an invalid format so the value could not convert to the suitable type, BeanUtils would throw an exception and it would propagate back to the user. Use only String type for ActionForm fields can display to the user the original values they input, but in your Action class code is needed to transform from String type to type used in business objects. Not all people like this. Today one more developer posted it as a bug. Ideally, we hope to use more types in a form bean while still able to display the original inputs to the user when a validation error occurs. I think the following solution can achieve it, 0. Basic validation, Valid Format and Required, should be handled during populating form bean. 1. In RequestProcessor class, processPopulate() should mimic processValidate(). It returns a boolean to indicate whether processPopulate is successful or not. If not successful, it should forward to the input page like processValidate does. 2. Instead of throwing exception, BeanUtils class should catch the exception for populating error and continue. It returns a list of the fields that have problem (normally invalid format). Error messages constructed based on these fields will be stored in Globals.ERROR_KEY. 3. When there is populating error, a HashMap is created to hold the original request parameters (all Strings, nested fields can have nested HashMaps). The HashMap is stored at a global key (Globals.xxx) in the request. 4. The html:form tag will get the stored HashMap and put it to Constants.BEAN_KEY for field tags to use (when there is populating error). Thus, you can use other types in form bean (nest business objects in form bean, for example) and Struts can still display the user's original input when in error. I tried it on Struts1.1-rc2 and it worked. I did not try complex cases such as array type and nested fields but I think it will work. What's your opinion? I began to look at Struts source code only recently and I'm still not quite familiar with the code. Comments from you people on whether it's worthwhile to implement it in Struts and the best way to do it if we decide to move on would be very helpful. Andrew
Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)
On Wed, 25 Feb 2004, Joe Germuska wrote: Perhaps this is understood, but I'm assuming that we also want to say that the RM owns the release tags for the release he or she is managing, and only the RM should *ever* move the tags? It's never been stated as such, but that's not a bad idea at all. I can't think of a good reason to move tags, other than to tweak things as part of the release process, and only the RM should be doing that. Now, where can we document this? ;-) -- Martin Cooper Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27236] - Form population automatically assign default value when parsing error occurs.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27236 Form population automatically assign default value when parsing error occurs. --- Additional Comments From [EMAIL PROTECTED] 2004-02-26 18:46 --- Why is this not a bug? User enters something that is not parseable to an integer into a form field, I expect that to be caught by the validator framework, instead here is what happens. In the process of transferring the form data into the actionform, my bean property is defined as an integer, so the BeanUtils try to convert the form field to an integer fails and defaults it to zero. Zero is valid so it passes my validator which is setup to verify that it's an integer. The javascript validation will catch this, but that can be turned off! Seem like the validator framework should work against the form data on the request not the ActionForm. Raj - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test posting
__ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.2.0 uploaded - Take 2
... and the source builds fine on my machine. Hubert Rabago --- Wendy Smoak [EMAIL PROTECTED] wrote: From: Martin Cooper [mailto:[EMAIL PROTECTED] Again, I'd appreciate it if someone could verify the integrity of the files, and let me know if they're OK. Hopefully, this one will be OK and I can go ahead and announce it to both lists. FWIW, the files in the .zip binary file work fine for me. The source .zip file unzipped okay. (I'm not set up to build it here, I just use the source with JSwat.) -- Wendy Smoak __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.2.0 uploaded - Take 2
From: Martin Cooper [mailto:[EMAIL PROTECTED] Again, I'd appreciate it if someone could verify the integrity of the files, and let me know if they're OK. Hopefully, this one will be OK and I can go ahead and announce it to both lists. FWIW, the files in the .zip binary file work fine for me. The source .zip file unzipped okay. (I'm not set up to build it here, I just use the source with JSwat.) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts 1.2.0 Test Build available
The Struts 1.2.0 Test Build is now available here: http://www.apache.org/~martinc/struts/v1.2.0/ This is the first Struts build being made available following the same test-and-release process that has been used successfully by the Tomcat team for some time. It is *not* an official Apache release. Once feedback has been collected on the stability and general quality of this build, a determination will be made as to whether it should be promoted to Alpha status. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
