DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 11:50 --- I believe you are incorrect in your assertion that release() is called for the tag. In both resin and tomcat release() is called when the container discards the tag body which has no relation to anything related to a particular tag invocation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17368] New: - html:select multiple does not populate form bean under jdk1.3
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=17368. 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=17368 html:select multiple does not populate form bean under jdk1.3 Summary: html:select multiple does not populate form bean under jdk1.3 Product: Struts Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I discovered that the struts1.1 nightly build I was using (jakarta-struts- 20030205.zip) does not populate the ActionForm indexed properties properly, when you are using the JDK1.3 (I used jdk1.3.1_02). The javabeans specification says that a javabean with an indexed propery can have the methods: - void setter(int index, PropertyType value) - PropertyType getter(int index) - void setter( PropertyType value[] ) - PropertyType[] getter() I defined an ActionForm bean with the three last signatures for my indexed property and concluded the following: - This does work under the conbination struts1.0 / JDK1.3 - This does work under the conbination struts1.1(nightly) / JDK1.4 (i used jdk1.4.0_03) - This does NOT work under the conbination struts1.1(nightly) / JDK1.3 In the last case, the ActionForm did not get populated with the selected values anymore. I simply switched the JAVA_HOME variable to test it under the two different JDK's (with tomcat versions 4.01,4.03 and 4.1.18). All tomcat versions had the same result. If I removed the getter method: - PropertyType getter(int index) all works fine. So why doesn't this method work properly under the conbination struts1.1 / jdk1.3? All other conbinations work fine. This behaviour is so strange I don't even know where to report this (JDK bug? struts bug? commons beanutils bug?). If you want a simple test application for this, i have one. So mail me if you want me to send it to you. Greetings, Luc Carpentier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17368] - html:select multiple does not populate form bean under jdk1.3
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=17368. 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=17368 html:select multiple does not populate form bean under jdk1.3 --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 12:16 --- Created an attachment (id=5000) Example application (without the WEB-INF/lib because it's to big) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17371] New: - HtmlTag throws NPE when sessions are disabled and locale property is false
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=17371.
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=17371
HtmlTag throws NPE when sessions are disabled and locale property is false
Summary: HtmlTag throws NPE when sessions are disabled and locale
property is false
Product: Struts
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
If a page that uses html:html locale=false (which is the default) also uses
%@ page session=false %, HtmlTag will throw an NPE. The problem is with the
following code in the getCurrentLocale method:
HttpSession session = pageContext.getSession();
if (this.locale (session == null)) {
session = ((HttpServletRequest) this.pageContext.getRequest()).getSession();
}
Locale current = (Locale) session.getAttribute(Globals.LOCALE_KEY);
If this.locale is false and pageContext.getSession() returns null, then the
session variable will still be null when session.getAttribute is invoked.
It's also questionable whether HtmlTag should blindly be creating a session or
setting the Globals.LOCALE_KEY session attribute. This should be handled by
RequestProcessor.processLocale.
A patch will follow that has currentLocale and getCurrentLocale just call
RequestUtils.retrieveUserLocale.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17371] - HtmlTag throws NPE when sessions are disabled and locale property is false
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=17371. 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=17371 HtmlTag throws NPE when sessions are disabled and locale property is false --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 13:30 --- Created an attachment (id=5002) Patch for proposed fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC1 release and Commons Logging 1.0.2
IMHO, this is the better forum for this discussion, since it's about the dependencies we choose to use when *developing* Struts. From a pure user viewpoint, these are blackbox developer decisions that do not affect their ability to simply plunk our JARs down. -Ted. Robert Leland wrote: I am moving this over to the struts-user list where it belongs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new variation on old question
You might as well be asking us for stock tips =:0) Point in fact, none of us have any control over when it will be released. If a user finds a drastic bug in the release candidate that has escaped our notice, then it is unlikely that it would be released until the issue is resolved. But since we don't know what people will find, it's impossible for us to anticipate whether it will need to be fixed, or how long the fix might take. But even, then there is no surety. The release is a democractic process. Any time we get more +1s then -1s, we can release. But whether any of us are willing to vote +1 depends on the what's in Bugzilla right now. Since we don't know what will be in Bugzilla tomorrow, we can't anticiapte how will vote tommorrow. The God's honest truth is that anyone watching this list and bugzilla knows as much about when this puppy will be released as the rest of us. You guess is as good as mine, or any other Committers. If you had been watching this list, then you would know that there is no chance for a 1.1 final to be released by Friday. It takes three days just to vote, and then more time to prepare the distribution. Not to mention that a RC that lasted less than a week or ten days would be worthless. But here's the bottom line: If you have to ask when it will be released, then assume it won't be. -Ted. Thomas L Roche wrote: I am NOT gonna ask, when do youse think 1.1 final will release, because I believe I know the answer. (Something like, when it's @$#%^*! ready! :-) But I would appreciate your _opinions_ (which will NOT be held against you in a court of law!) on the odds that 1.1 final will ship on or before F 28 Mar 03. (Just a date that, umm, some manager hit when s/he threw a dart at a calendar :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations
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=17299. 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=17299 Page variable not set on DynaValidatorForms for mutlipage validations --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 14:01 --- On a non-dynamic ValidatorForm it gets called as long as the field exists on the submitted page, just like all other setter methods for fields on the form. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
David Graham, 1.1 RC1 MVC
While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: David Graham, 1.1 RC1 MVC
+1 - I'll drink to that...wait a minute.hell, I'll drink to anything ;) -- James Mitchell Software Engineer/Struts Evangelist Beer is the reason we get up each afternoon. Ray McNeill -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 9:03 AM To: [EMAIL PROTECTED] Subject: David Graham, 1.1 RC1 MVC While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - 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: David Graham, 1.1 RC1 MVC
+1 --- Ted Husted [EMAIL PROTECTED] wrote: While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: David Graham, 1.1 RC1 MVC
+1 Ted Husted wrote: While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. Does this mean he gets a copy of your book, ;-) ! When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 15:07 --- Hi all again! We've upgraded to struts 1.1rc1, and the problem still seems to remain. Due to the fact that this is a production application and our customer is very unhappy with it going down every couple of hours from memory leaks, I'm taking out the iterate tags for now. Any help is still greatly appreciated, and thank you :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 15:10 --- Page 172 of the JSP 1.2 spec states, The page compiler guarantees that release() will be invoked on the Tag handler before the handler is released to the GC. So, release is guaranteed to be called when your app is low on memory and the gc runs. It doesn't matter that it's not called for every invocation because the Iterator and Collection properties will be overwritten and released. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 15:13 --- The page compiler guarantees that release() will be invoked on the Tag handler before the handler is released to the GC. So, release is guaranteed to be called when your app is low on memory and the gc runs. actually, wouldn't it have to be free of pointers for the gc to attempt to call it and have the release() method run? In other words, if the pageContext or something (and I don't know what would hold it) was still holding onto that tag, then the GC would ignore it, and the release wouldn't run. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 15:18 --- True, but Struts doesn't keep references to the tag objects, the container does. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: David Graham, 1.1 RC1 MVC
My self deprecating nature makes it difficult to accept but I really appreciate the recognition. I enjoy being part of this team and respect all of your opinions. Thank you, David From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: David Graham, 1.1 RC1 MVC Date: Tue, 25 Feb 2003 09:02:54 -0500 While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: David Graham, 1.1 RC1 MVC
+1 Robert S. Sfeir wrote: +1 On Tuesday, Feb 25, 2003, at 09:02 US/Eastern, Ted Husted wrote: While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - 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]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 16:31 --- So, if Joshua had a chance, it would be great if we could confirm the issue remains when using JSTL or some other custom tag. If the problem is in the container, there isn't anything Struts can do about it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17273] - Recycled instance of form bean returned even if invalid type
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=17273. 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=17273 Recycled instance of form bean returned even if invalid type [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 16:34 --- I can setup a Test Case for this (unless someone is eager to beat me to it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
On Tue, 25 Feb 2003, David Graham wrote: Date: Tue, 25 Feb 2003 11:09:10 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 So dbcp, pool, and fileupload still need work. Arron fixed an important bug with the nested taglib but he recommended that we not include the fix in 1.1 because it touched a lot of the nested tags. Are we sure we don't want to include that fix in 1.1? The nested tags are badly broken in Tomcat 4.1.18 if we don't include the fix. I think that's definitely worth considering, but separately from the scope of deciding on external dependencies. The same can be said for any nontrivial bug fix between now and final release. On the topic of the nested tags, do they work if you disable tag pooling in 4.1.18? If not, then I think we definitely have to fix this. If they do, then it's still worth thinking about, but not quite as urgent. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependent Packages in Struts 1.1
I think that the just released commons-net 1.0 has taken over from jakarta-oro. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Dependent Packages in Struts 1.1 snip/ jakarta-oro -- The latest public release (2.0.7) is stable and seems to fit the bill. Everything else comes from within our own workspace, and I'm assuming we're going to use essentially the current HEAD branch plus critical bug fixes, and continue our plan to package struts-el in the contrib directory as we do today. Craig - 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 17389] New: - i18n, getting tiles to pick up xml definitions file based on locale's variant
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=17389. 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=17389 i18n, getting tiles to pick up xml definitions file based on locale's variant Summary: i18n, getting tiles to pick up xml definitions file based on locale's variant Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Tiles framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The tiles definition xml files are not being loaded accordingly when the locale is being set to a specific variant. Only language and country is loaded, variant is not taken into account. issue lies at I18nFactorySet.calculatePostixes(...) method. Problem have been fixed. I haved emailed the patch to Cedric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17389] - i18n, getting tiles to pick up xml definitions file based on locale's variant
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=17389. 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=17389 i18n, getting tiles to pick up xml definitions file based on locale's variant --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 18:52 --- You should attach the patch to this bug report instead of mailing it to individual committers. The problem is more likely to get fixed that way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sorry I got off topic there. Why do we have a dependency on ORO? Does one of the commons-* libraries use it? Yes, Commons Validator uses it. -- Martin Cooper Re nested: Arron has released a fixed jar for people to download separately from Struts. This may be confusing to people who expect nested to work out of the 1.1 box. I don't use nested so I have no vested interest in whether it's fixed in 1.1 or 1.2. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 Date: Tue, 25 Feb 2003 10:17:21 -0800 (PST) On Tue, 25 Feb 2003, David Graham wrote: Date: Tue, 25 Feb 2003 11:09:10 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 So dbcp, pool, and fileupload still need work. Arron fixed an important bug with the nested taglib but he recommended that we not include the fix in 1.1 because it touched a lot of the nested tags. Are we sure we don't want to include that fix in 1.1? The nested tags are badly broken in Tomcat 4.1.18 if we don't include the fix. I think that's definitely worth considering, but separately from the scope of deciding on external dependencies. The same can be said for any nontrivial bug fix between now and final release. On the topic of the nested tags, do they work if you disable tag pooling in 4.1.18? If not, then I think we definitely have to fix this. If they do, then it's still worth thinking about, but not quite as urgent. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
No. Jakarta ORO is a text processing package that Validator uses for its regular expression functionality. Commons Net is an internet protocol suite. Both packages did originate at ORO, Inc., though. ;-) -- Martin Cooper Byrne, Steven [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think that the just released commons-net 1.0 has taken over from jakarta-oro. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Dependent Packages in Struts 1.1 snip/ jakarta-oro -- The latest public release (2.0.7) is stable and seems to fit the bill. Everything else comes from within our own workspace, and I'm assuming we're going to use essentially the current HEAD branch plus critical bug fixes, and continue our plan to package struts-el in the contrib directory as we do today. Craig - 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 17389] - i18n, getting tiles to pick up xml definitions file based on locale's variant
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=17389. 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=17389 i18n, getting tiles to pick up xml definitions file based on locale's variant --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 19:03 --- Created an attachment (id=5021) see attached file... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17389] - i18n, getting tiles to pick up xml definitions file based on locale's variant
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=17389. 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=17389 i18n, getting tiles to pick up xml definitions file based on locale's variant --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 19:07 --- Sorry, forgot to attach the file. I have talked to Cedric about this, and he's aware of the problem. Thanks... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependent Packages in Struts 1.1
red-face victim=me / -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 11:01 AM To: [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 No. Jakarta ORO is a text processing package that Validator uses for its regular expression functionality. Commons Net is an internet protocol suite. Both packages did originate at ORO, Inc., though. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17391] New: - HTML text tag needs to format its content like Bean write
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=17391. 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=17391 HTML text tag needs to format its content like Bean write Summary: HTML text tag needs to format its content like Bean write Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The HTML text tag should format its content in the same way as the Bean write tag. From the Bean write tag documentation: format - Specifies the format string to use to convert bean or property value to the String. If nothing specified, then default format string for value data type will be searched in message resources by according key. formatKey - Specifies the key to search format string in application resources. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
Martin Cooper wrote: Craig R. McClanahan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] As the topic comes up regularly, it strikes me that we haven't had any formal discussions or decisions on what versions of our dependent packages to include in Struts 1.1 final. Most of them are probably non-controversial, but there are a couple of interesting cases. Let's talk about the whole list on this mail thread. commons-fileupload -- Martin just published a beta of this. By our standard rules, we'll need a final release before we can really use it. Yes. Since announcing the Beta, there has been an uptick in user activity, so there are a number of bugs that need to be addressed. Unfortunately, FileUpload seems to be a one man show (me) at the moment, with the original contributors being conspicuously absent. In addition, there has been some discussion about merging with another (non-Jakarta) file upload project. I need to get back in there and catch up. Jon Scott Stevens suggested instead of creating a new another fileupload package that maybe the current one could be improved on. I would vote not to go there for 1.1, and I am sure you would rather get a 1.0 released based on the current code, before merging with another file upload package. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 19:58 --- If there is a bug here, I don't see how it can possibly be in Struts. One tag instance holds exactly one collection and iterator reference. When the tag is reused or released, any existing references are cleared, either by overwriting the values or by setting them to null in release(). There is nowhere that the iterator tag could accumulate references to more than one of each of these. The only way for memory usage to be consumed as Joshua describes is for the container to be continually allocating new tag handler instances without releasing existing ones. Struts has absolutely no control over that. Joshua, since you have a profiler at your disposal, can you try taking your analysis one more step? You said you saw references from the iterator tags to the vectors, and I'm betting that you'll also see references from the container to the iterator tags. Also, what container are you using, and what JVM? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
Yes. Since announcing the Beta, there has been an uptick in user activity, so there are a number of bugs that need to be addressed. Unfortunately, FileUpload seems to be a one man show (me) at the moment, with the original contributors being conspicuously absent. It looks like there are 2 outstanding bugs on fileupload. One of them appears to be a simple fix and the other has a patch. The non-ascii file names bug 14120 might be marked as later if we need a 1.0 release soon and the patch doesn't fix it. David _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 20:11 --- sure, here's an example trace: (further on into tomcat) - field theServlet of JspServletWrapper - field _jspx_tagPool_logic_iterate_type_indexId_id_collection of (my jsp) - field handlers of TagHandlerPool - class array context - field collection of IterateTag - (my Vector) I'm using tomcat 4.1.18 and Sun Java 1.4 on Solaris and Linux. I can definatly see that this isn't Struts' problem. I've replaced all iterate tags with for loops and the problem has gone away (now I've just got a memory hog on my hands ;) ). I haven't tried JSTL or other custom tag loops in the code, as I haven't had time. I'd still like to know why this is happening, but I don't expect to get it fixed here :) Thanks to all for your time and input! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 20:17 --- Have you tried disabling tag pooling? See: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
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=17165. 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=17165 logic:iterate tag not releasing collections from memory --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 20:28 --- hey that cleared it right up! thanks alot :) Goes to show you you should always rtfm ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17391] - HTML text tag needs to format its content like Bean write
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=17391. 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=17391 HTML text tag needs to format its content like Bean write [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 21:45 --- What you're suggesting won't work. Even if you force it, it will only lead to problems on form submittal, due to conversion errors. For example (I know this works, because I have a running example): Implementing what you suggest would have the same effect as the following (except it would only be 1 line): bean:define id=myValue bean:write name=%=Constants.BEAN_KEY% property=integerValue format=$###,###/ /bean:define html:text property=integerValue value=%=myValue%/br Now, the page renders fine the first time. In fact, if myform.getIntegerValue() has '300' as it's value, then it displays '$300' as expected. However, when I submit this page, conversion errors cause the '300' to be lost. In fact, even this simple work-around doesn't work.because if we are returned to this page (for whatever reason) and getIntegerValue returns null, then an exception is thrown from the define tag. The only way around this would be to make our field a String, but doing that means that it won't format correctly, since a Number is required. Back to square one. Unless someone can find a way to make this work I'm going to mark it as 'Won't Fix'. In the future, please post these issues to the struts-user list for discussion first. Thank you. James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17391] - HTML text tag needs to format its content like Bean write
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=17391. 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=17391 HTML text tag needs to format its content like Bean write --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 21:55 --- The bug poster didn't say the form property wasn't a String, even if it was a String, doesn't ConvertUtils use NumberFormat to convert the String to a Number? That would handle commas and dollar signs. I know I have used Struts forms in the past that allowed the user to enter commas in form fields. I just did the formatting in the bean and used NumberFormat myself to convert the String to Number in the validate function. Having the format attribute in the tag would be convenient but it's not critical. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Relative action URL's for FormTag
I needed (for reasons beyond my control) to have html:form.. create an action=
with a relative
URL. Searching the mailing list, I ran across others who were seeking similar
functionality. I
wrote up a simple addition to FormTag.java that allows an optional isRelative
attribute inside the
form tag.
Image tags have something functionally equivalent, so I'm guessing it may be
functionality you are
interested in.
If you need something else from me, let me know.
Thanks,
Erik
This diff is against 1.1rc1
--- FormTag.java.rc12003-02-25 15:56:32.0 -0600
+++ FormTag.java.rc1.new2003-02-25 15:56:32.0 -0600
@@ -214,6 +214,12 @@
*/
protected String beanType = null;
+/**
+ * Whether or not the action= should be a relative URL. Default is
+ * false, to maintain backwards compatibility.
+ */
+protected String isRelative = null;
+
// - Properties
/**
@@ -488,6 +494,23 @@
}
+/**
+ * Is the action= relative? a value of true (case insensitive) indicates it is
+ *
+ * @param value
+ */
+public void setIsRelative (String value) {
+
+this.isRelative = value;
+
+}
+
+public String getIsRelative () {
+
+return isRelative;
+
+}
+
// - Public Methods
/**
@@ -509,7 +532,11 @@
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
- results.append(response.encodeURL(RequestUtils.getActionMappingURL(action,
pageContext)));
+if (true.equalsIgnoreCase(isRelative ) ) {
+results.append(response.encodeURL(action));
+} else {
+
results.append(response.encodeURL(RequestUtils.getActionMappingURL(action,
pageContext)));
+}
results.append(\);
if (styleClass != null) {
results.append( class=\);
@@ -696,6 +723,7 @@
styleId = null;
target = null;
type = null;
+isRelative = null;
}
--- struts-html.tld.rc1 2003-02-25 15:56:32.0 -0600
+++ struts-html.tld.rc1.new 2003-02-25 15:56:32.0 -0600
@@ -618,6 +618,11 @@
rtexprvaluetrue/rtexprvalue
/attribute
attribute
+nameisRelative/name
+requiredfalse/required
+rtexprvaluetrue/rtexprvalue
+/attribute
+attribute
nameenctype/name
requiredfalse/required
rtexprvaluetrue/rtexprvalue
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17391] - HTML text tag needs to format its content like Bean write
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=17391. 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=17391 HTML text tag needs to format its content like Bean write --- Additional Comments From [EMAIL PROTECTED] 2003-02-25 22:43 --- This sounds useful on the face of it, but in practise I believe it is untenable. This is due to the round-trip nature of the html:text tag and its interaction with the form bean. In addition, such an attribute results in both the Action (or possibly ActionForm) and the JSP page having to have (the same) knowledge of the text formatting. Suppose that your form bean property has the value 300 (as a String). When the page is displayed, the value in the text box might now be shown as $300. If the user now submits the form - without changes - the form bean now has the value $300. Notice that the property value changed *without the user making any change to the value*. The code that put 300 in the property now has to deal with $300 coming back, and has to know the specific format that the JSP page used, in order to be able to untangle the text and retrieve the real value. In addition, as James points out, going back to the JSP page without modifying the property value will cause the formatting to fail. This is not related to whether the property is a string or an integer. Trying to format $300 as a currency value will fail even if there is an implicit string-to-number conversion in the format code, because $300 is not a valid number. Even if the formatting simply prepended a '$', now you'd end up displaying $$300. This just isn't workable. If the property value needs formatting, then the formatting and the parsing of that format need to both happen either in the ActionForm or in the Action itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 17391] - HTML text tag needs to format its content like Bean write
The bug poster didn't say the form property wasn't a String,
even if it was a String, doesn't ConvertUtils use NumberFormat
to convert the String to a Number?
No, from WriteTag.java:338
...
...
// Return String object as is.
if ( value instanceof java.lang.String ) {
return (String)value;
} else {
...
...
Also, something else I forgot to mentionthe example I use has
convertNull set to true so if you remove that, you'll be seeing '$0' for
any submitted '$300' anyway.
--
James Mitchell
Software Engineer/Struts Evangelist
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 25, 2003 4:56 PM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 17391] - HTML text tag needs to
format its content like Bean write
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=17391.
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=17391
HTML text tag needs to format its content like Bean write
--- Additional Comments From [EMAIL PROTECTED] 2003-02-25
21:55 ---
The bug poster didn't say the form property wasn't a String, even if it
was a
String, doesn't ConvertUtils use NumberFormat to convert the String to a
Number? That would handle commas and dollar signs. I know I have used
Struts
forms in the past that allowed the user to enter commas in form fields.
I just
did the formatting in the bean and used NumberFormat myself to convert
the
String to Number in the validate function.
Having the format attribute in the tag would be convenient but it's not
critical.
-
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]
committers attention - just a few moments...
Peoples, I'm waiting on a call in the post below about the nested tags. I know they're not everyone's favorite component, but I do need committer attention to form the game plan as it's not the typical bug fix. It's hard to form a consensus opinion on the one response I have. Copied below for convenience. Arron. Original Post___ Defenders of the faith, Just a small one to say the problem of of not being able to run the nested tag apps in Tomcat 4.1.18's funky Jasper engine has been tackled. I'd commit it, but the codebase being under release conditions, and for the fact that it's no simple few line bug fix. The internals have changed to leverage the request object more completely (was originally just used to enable the recursive JSP markup). The NestedPropertyHelper has been gutted and mostly re-implemented, and all the nested tags have been touched to accomodate the change. Instead of walking the tag hierarchy, all the child tags now pick up on the nested reference within the request object directly. The property handling is now more pessimistic, and resets everything it touches. All effort was made to respect all the minor changes the tags have undergone in fixing past bugs. The fact that most of it has changed means that I don't want it in this release, but the fact that it allows people to deploy in the latest tomcat release is important, something blocking an upgrade path for a lot of people. What about, once the release is out, then the update to the tags committed, and release a bug-fix release for the new nested tags (1.1.1)?... kind of like 1.0.2 was to 1.0.1?... Too unstable for 1.1 so close to release, but too important to let it slip for over a year for it to come out. Needless to say it works on my apps :), but I'm asking the nested tags user base to jump onto it and give it a test run to see if it works for them. For those nesters looking on, there's a jar at... http://www.keyboardmonkey.com/downloads/km-nested-v2.jar ...just throw it into the WEB-INF/lib directory, your classloader should pick them up before struts.jar. If not, delete the tags from struts.jar and give it another bash. Anyways, just thought I'd put it forward. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). -Original Message- From: Arron Bates [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 3:03 PM To: [EMAIL PROTECTED] Subject: committers attention - just a few moments... Peoples, I'm waiting on a call in the post below about the nested tags. I know they're not everyone's favorite component, but I do need committer attention to form the game plan as it's not the typical bug fix. It's hard to form a consensus opinion on the one response I have. Copied below for convenience. Arron. Original Post___ -- -- Defenders of the faith, Just a small one to say the problem of of not being able to run the nested tag apps in Tomcat 4.1.18's funky Jasper engine has been tackled. I'd commit it, but the codebase being under release conditions, and for the fact that it's no simple few line bug fix. The internals have changed to leverage the request object more completely (was originally just used to enable the recursive JSP markup). The NestedPropertyHelper has been gutted and mostly re-implemented, and all the nested tags have been touched to accomodate the change. Instead of walking the tag hierarchy, all the child tags now pick up on the nested reference within the request object directly. The property handling is now more pessimistic, and resets everything it touches. All effort was made to respect all the minor changes the tags have undergone in fixing past bugs. The fact that most of it has changed means that I don't want it in this release, but the fact that it allows people to deploy in the latest tomcat release is important, something blocking an upgrade path for a lot of people. What about, once the release is out, then the update to the tags committed, and release a bug-fix release for the new nested tags (1.1.1)?... kind of like 1.0.2 was to 1.0.1?... Too unstable for 1.1 so close to release, but too important to let it slip for over a year for it to come out. Needless to say it works on my apps :), but I'm asking the nested tags user base to jump onto it and give it a test run to see if it works for them. For those nesters looking on, there's a jar at... http://www.keyboardmonkey.com/downloads/km-nested-v2.jar ...just throw it into the WEB-INF/lib directory, your classloader should pick them up before struts.jar. If not, delete the tags from struts.jar and give it another bash. Anyways, just thought I'd put it forward. Arron. - 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]
[proposal] Add Validating Two Fields to Validator (codeincluded)
I would like to propose that we add the validateTwoFields functionality to
the validator. I don't have the source, so I can't submit a true patch,
but hopefully this e-mail will get the ball rolling.
Add this method, in my case it's in org.appfuse.webapp.util.ValidationUtil:
public static boolean validateTwoFields(Object bean, ValidatorAction
va,
Field field, ActionErrors errors,
HttpServletRequest request) {
String value =
ValidatorUtil.getValueAsString(bean,
field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtil.getValueAsString(bean,
sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(),
Resources.getActionError(request, va, field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(request, va, field));
return false;
}
}
return true;
}
Then in validation-rules.xml - add the following for server-side AND
client-side validation:
validator name=twofields
classname=org.appfuse.webapp.util.ValidationUtil
method=validateTwoFields
methodParams=java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest
depends=required
msg=errors.twofields
javascript![CDATA[
function validateTwoFields(form) {
var bValid = true;
var focusField = null;
var i = 0;
var fields = new Array();
oTwoFields = new twofields();
for (x in oTwoFields) {
var field = form[oTwoFields[x][0]];
var secondField =
form[oTwoFields[x][2](secondProperty)];
if (field.type == 'text' ||
field.type == 'textarea' ||
field.type == 'select-one' ||
field.type == 'radio' ||
field.type == 'password') {
var value;
var secondValue;
// get field's value
if (field.type ==
select-one) {
var si =
field.selectedIndex;
value =
field.options[si].value;
secondValue =
secondField.options[si].value;
} else {
value = field.value;
secondValue =
secondField.value;
}
if (value != secondValue) {
if (i == 0) {
focusField = field;
}
fields[i++] = oTwoFields[x][1];
bValid = false;
}
}
}
if (fields.length 0) {
focusField.focus();
alert(fields.join('\n'));
}
return bValid;
}]]
/javascript
/validator
I haven't thouroughly tested this, but it's working for me on a
password/confirm password scenario.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
On Tue, 25 Feb 2003, Karr, David wrote: Date: Tue, 25 Feb 2003 15:06:52 -0800 From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: committers attention - just a few moments... Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). I think David articulates a rational approach. If you think the fix for nested tags should go in (in spite of being a larger patch than we might be normally comfortable with), and you've tested it as much as you can, I'm certainly not going to argue. Worst case - we do an RC2 with this fix to give the world one more shot at proving it's still got a problem. Craig -Original Message- From: Arron Bates [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 3:03 PM To: [EMAIL PROTECTED] Subject: committers attention - just a few moments... Peoples, I'm waiting on a call in the post below about the nested tags. I know they're not everyone's favorite component, but I do need committer attention to form the game plan as it's not the typical bug fix. It's hard to form a consensus opinion on the one response I have. Copied below for convenience. Arron. Original Post___ -- -- Defenders of the faith, Just a small one to say the problem of of not being able to run the nested tag apps in Tomcat 4.1.18's funky Jasper engine has been tackled. I'd commit it, but the codebase being under release conditions, and for the fact that it's no simple few line bug fix. The internals have changed to leverage the request object more completely (was originally just used to enable the recursive JSP markup). The NestedPropertyHelper has been gutted and mostly re-implemented, and all the nested tags have been touched to accomodate the change. Instead of walking the tag hierarchy, all the child tags now pick up on the nested reference within the request object directly. The property handling is now more pessimistic, and resets everything it touches. All effort was made to respect all the minor changes the tags have undergone in fixing past bugs. The fact that most of it has changed means that I don't want it in this release, but the fact that it allows people to deploy in the latest tomcat release is important, something blocking an upgrade path for a lot of people. What about, once the release is out, then the update to the tags committed, and release a bug-fix release for the new nested tags (1.1.1)?... kind of like 1.0.2 was to 1.0.1?... Too unstable for 1.1 so close to release, but too important to let it slip for over a year for it to come out. Needless to say it works on my apps :), but I'm asking the nested tags user base to jump onto it and give it a test run to see if it works for them. For those nesters looking on, there's a jar at... http://www.keyboardmonkey.com/downloads/km-nested-v2.jar ...just throw it into the WEB-INF/lib directory, your classloader should pick them up before struts.jar. If not, delete the tags from struts.jar and give it another bash. Anyways, just thought I'd put it forward. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
I also agree with David. The responses I've seen to your fix indicate that it worked. I think it would be appropriate to commit the fixes now for release in 1.1. I think an RC2 that included your fix would be appropriate after we deal with the rest of the open bugs on RC1. David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: committers attention - just a few moments... Date: Tue, 25 Feb 2003 15:06:52 -0800 Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). -Original Message- From: Arron Bates [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 3:03 PM To: [EMAIL PROTECTED] Subject: committers attention - just a few moments... Peoples, I'm waiting on a call in the post below about the nested tags. I know they're not everyone's favorite component, but I do need committer attention to form the game plan as it's not the typical bug fix. It's hard to form a consensus opinion on the one response I have. Copied below for convenience. Arron. Original Post___ -- -- Defenders of the faith, Just a small one to say the problem of of not being able to run the nested tag apps in Tomcat 4.1.18's funky Jasper engine has been tackled. I'd commit it, but the codebase being under release conditions, and for the fact that it's no simple few line bug fix. The internals have changed to leverage the request object more completely (was originally just used to enable the recursive JSP markup). The NestedPropertyHelper has been gutted and mostly re-implemented, and all the nested tags have been touched to accomodate the change. Instead of walking the tag hierarchy, all the child tags now pick up on the nested reference within the request object directly. The property handling is now more pessimistic, and resets everything it touches. All effort was made to respect all the minor changes the tags have undergone in fixing past bugs. The fact that most of it has changed means that I don't want it in this release, but the fact that it allows people to deploy in the latest tomcat release is important, something blocking an upgrade path for a lot of people. What about, once the release is out, then the update to the tags committed, and release a bug-fix release for the new nested tags (1.1.1)?... kind of like 1.0.2 was to 1.0.1?... Too unstable for 1.1 so close to release, but too important to let it slip for over a year for it to come out. Needless to say it works on my apps :), but I'm asking the nested tags user base to jump onto it and give it a test run to see if it works for them. For those nesters looking on, there's a jar at... http://www.keyboardmonkey.com/downloads/km-nested-v2.jar ...just throw it into the WEB-INF/lib directory, your classloader should pick them up before struts.jar. If not, delete the tags from struts.jar and give it another bash. Anyways, just thought I'd put it forward. Arron. - 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] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). David I think David articulates a rational approach. If you think the fix for nested tags should go in (in spite of being a larger patch than we might be normally comfortable with), and you've tested it as much as you can, I'm certainly not going to argue. Worst case - we do an RC2 with this fix to give the world one more shot at proving it's still got a problem. Craig This is the feedback I'm after. Had I simply committed the patch that is on the big side, I would have been trounced. Especially seeing that time hasn't let me play apache recently, to then walk in and make such a large play (on RC1 day no less). Wouldn't have gone over well I imagine. Arron. BTW: So far, none of the early adopters have said their apps have broken with the new changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new variation on old question
Tom Roche Mon, 24 Feb 2003 23:29:33 -0500 I would appreciate your _opinions_ (which will NOT be held against you in a court of law!) on the odds that 1.1 final will ship on or before F 28 Mar 03. David Graham Mon, 24 Feb 2003 22:08:59 -0700 Not good. There are 7 open bug reports to deal with and I'd like to give people a bit more time to test their apps on the RCs. Thanks! All I wanted was a gut feel ... _not_ another lecture on The Apache Way :-P - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17371] - HtmlTag throws NPE when sessions are disabled and locale property is false
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=17371. 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=17371 HtmlTag throws NPE when sessions are disabled and locale property is false --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 03:06 --- Scratch that last attachment. It's close, but I'll post something a little better that includes Javadoc updates and a small change to RequestUtils.retrieveUserLocale. Just want to reemphasize that the patch removes the ability of HtmlTag to store a locale in the session. This is already handled through the ControllerConfig locale property and the RequestProcessor.processLocale method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
dgraham 2003/02/25 20:48:57
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
retrieveUserLocale now uses the request.getLocale() method for finding the
user's preferred locale. If user has not specified this with Accept-Language
header, the server default locale is used.
Revision ChangesPath
1.90 +5 -5
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- RequestUtils.java 25 Feb 2003 04:58:30 - 1.89
+++ RequestUtils.java 26 Feb 2003 04:48:56 - 1.90
@@ -886,7 +886,7 @@
}
if (userLocale == null) {
-userLocale = defaultLocale;
+userLocale = pageContext.getRequest().getLocale();
}
return userLocale;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html HtmlTag.java
dgraham 2003/02/25 20:51:09
Modified:src/share/org/apache/struts/taglib/html HtmlTag.java
Log:
The tag now uses RequestUtils.retrieveUserLocale for looking up the appropriate
locale. Using that method protects us from needlessly creating a session
for PR# 17371.
Revision ChangesPath
1.10 +10 -22
jakarta-struts/src/share/org/apache/struts/taglib/html/HtmlTag.java
Index: HtmlTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/HtmlTag.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HtmlTag.java 8 Dec 2002 06:54:51 - 1.9
+++ HtmlTag.java 26 Feb 2003 04:51:09 - 1.10
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2001 The Apache Software Foundation. All rights
+ * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -70,6 +70,7 @@
import org.apache.struts.Globals;
import org.apache.struts.util.MessageResources;
+import org.apache.struts.util.RequestUtils;
import org.apache.struts.util.ResponseUtils;
@@ -238,28 +239,15 @@
*/
protected Locale getCurrentLocale() {
-// Create a new session if necessary
-HttpSession session = pageContext.getSession();
-if (this.locale (session == null)) {
-session = ((HttpServletRequest)
this.pageContext.getRequest()).getSession();
-}
-
-// Return any currently set Locale in our session
-Locale current = (Locale) session.getAttribute(Globals.LOCALE_KEY);
-if (current != null) {
-return (current);
-}
-
-// If client doesn't specify a locale preference in header then default for
-// server will be returned.
-current = pageContext.getRequest().getLocale();
+Locale userLocale = RequestUtils.retrieveUserLocale(pageContext,
Globals.LOCALE_KEY);
// Store a new current Locale, if requested
if (this.locale) {
-session.setAttribute(Globals.LOCALE_KEY, current);
+HttpSession session = ((HttpServletRequest)
this.pageContext.getRequest()).getSession();
+session.setAttribute(Globals.LOCALE_KEY, userLocale);
}
-return (current);
+return userLocale;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17371] - HtmlTag throws NPE when sessions are disabled and locale property is false
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=17371. 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=17371 HtmlTag throws NPE when sessions are disabled and locale property is false [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 04:54 --- Removing that functionality breaks backwards compatibility and removes much of the utility of using the locale attribute at all. I've replaced the locale finding code with a call to RequestUtils.retrieveUserLocale() so it won't create a session. However, a session is still created and a locale object stored there if you use the tag's locale=true attribute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17281] - Add validateLongRange to Validator
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=17281. 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=17281 Add validateLongRange to Validator [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Summary|Validator Range |Add validateLongRange to ||Validator --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 05:03 --- This seems to be an enhancement request due the current non-existant support for checking long ranges. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug #17156 Validate Integer?
That bug states that validate required does not work with an ActionForm property with type java.lang.Integer. Indeed, I tested this with the struts-validator webapp's type form and required doesn't seem to run for that field when I changed it from String to Integer. What does happen is that a 0 shows up in the text box while the other fields remain blank and their required error messages are displayed. Is this simply a usage limitation of the validator? One more reason to use Strings for all ActionForm properties? I'm guessing that 0 shows up because that's the default value for an Integer object when it's created. I don't know enough about this to close the bug as INVALID or fix it. Thoughts? Thanks, Dave _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new variation on old question
Thomas L Roche wrote: Not good. There are 7 open bug reports to deal with and I'd like to give people a bit more time to test their apps on the RCs. Thanks! All I wanted was a gut feel ... _not_ another lecture on The Apache Way :-P LOL =:) David, quite wisely, simply pointed out that RC1 only shipped on Sunday and that we already have several new tickets. All facts of public record. No one offered an opinion or gut feel, and probably won't. The point of the lecture is that our guestimates have never been right before, and probably never will be. Anyone who acted on our opinion or gut feel would almost certainly be disappointed. There is no value add. Pretending otherwise would be arrogant at best, and dishonest at worse. The process is controlled by the Community and the coincidence of how much volunteer time the Committers have available. This produces excellent software, but never according to schedule. The best advice will always be: if you need to ask when the next release will be available, then you can't afford to use it. That's not always what people want to hear, but it is the truth. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug #17156 Validate Integer?
Between 1.0 and 1.1 there's a switch that determines whether numerics like Integer go to 0 or to null. If you have the test setup, try it again with convertNull set to true as an ActionServlet parameter. If it then works, we can just document the condition. Since numerics are not recommended for ActionForms, we don't need to solution to be particularly elegant =:0) -Ted. David Graham wrote: That bug states that validate required does not work with an ActionForm property with type java.lang.Integer. Indeed, I tested this with the struts-validator webapp's type form and required doesn't seem to run for that field when I changed it from String to Integer. What does happen is that a 0 shows up in the text box while the other fields remain blank and their required error messages are displayed. Is this simply a usage limitation of the validator? One more reason to use Strings for all ActionForm properties? I'm guessing that 0 shows up because that's the default value for an Integer object when it's created. I don't know enough about this to close the bug as INVALID or fix it. Thoughts? Thanks, Dave _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
Arron, My vote would be to move ahead with the changes. I have not reviewed the changes, but it looked like there might be some missmatched resets that would cause problems in the latest RC. I used the nested tags extensively on several sites and would rather deal with minor bugs/patches than sporadic problems. Somehow I missed your message about a nested patch and just downloaded it this evening. I tested your new jar against several sites and came up with one problem. I have not spent the time to debug this properly, and I am using a nightly build from a couple of weeks ago, but it appears that there may be a problem. I have a fairly simple debugging page nested tags to display values from the JVM. I will download and build the latest nightly and retest. If the problem is still there I will post another message and send you that very simple page that appears to be failing. I will also try to test against a couple of other installations that use nested tags. David Morris [EMAIL PROTECTED] 02/25/03 16:42 PM Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). David I think David articulates a rational approach. If you think the fix for nested tags should go in (in spite of being a larger patch than we might be normally comfortable with), and you've tested it as much as you can, I'm certainly not going to argue. Worst case - we do an RC2 with this fix to give the world one more shot at proving it's still got a problem. Craig This is the feedback I'm after. Had I simply committed the patch that is on the big side, I would have been trounced. Especially seeing that time hasn't let me play apache recently, to then walk in and make such a large play (on RC1 day no less). Wouldn't have gone over well I imagine. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/logic ELForwardTag.java ELIterateTag.java ELMatchTag.java ELMessagesNotPresentTag.java ELMessagesPresentTag.java ELNotMatchTag.java
dmkarr 2003/02/25 22:12:26
Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/bean
ELMessageTag.java ELPageTag.java ELResourceTag.java
ELSizeTag.java ELStrutsTag.java
contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELBaseTag.java ELErrorsTag.java ELFormTag.java
ELImgTag.java ELMessagesTag.java
contrib/struts-el/src/share/org/apache/strutsel/taglib/logic
ELForwardTag.java ELIterateTag.java ELMatchTag.java
ELMessagesNotPresentTag.java
ELMessagesPresentTag.java ELNotMatchTag.java
Log:
Changed some leftover ExpressionUtil.evalNotNull() calls into EvalHelper.eval()
calls. This fixed a problem in ELErrorsTag because the name attribute of
ErrorsTag has a non-null default value. Using EvalHelper lets me easily avoid
calling the setter if the value is null.
PR: 17375
Revision ChangesPath
1.5 +7 -7
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELMessageTag.java
Index: ELMessageTag.java
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELMessageTag.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ELMessageTag.java 19 Feb 2003 03:49:50 - 1.4
+++ ELMessageTag.java 26 Feb 2003 06:12:25 - 1.5
@@ -63,7 +63,7 @@
import javax.servlet.jsp.JspException;
import org.apache.struts.taglib.bean.MessageTag;
-import org.apache.taglibs.standard.tag.el.core.ExpressionUtil;
+import org.apache.strutsel.taglib.utils.EvalHelper;
import org.apache.taglibs.standard.tag.common.core.NullAttributeException;
/**
@@ -297,8 +297,8 @@
ClassattrType)
throws JspException, NullAttributeException
{
-return (ExpressionUtil.evalNotNull(message, attrName, attrValue,
- attrType, this, pageContext));
+return (EvalHelper.eval(message, attrName, attrValue,
+attrType, this, pageContext));
}
/**
1.5 +7 -7
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELPageTag.java
Index: ELPageTag.java
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELPageTag.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ELPageTag.java19 Feb 2003 03:49:50 - 1.4
+++ ELPageTag.java26 Feb 2003 06:12:25 - 1.5
@@ -62,7 +62,7 @@
import org.apache.struts.taglib.bean.PageTag;
import javax.servlet.jsp.JspException;
-import org.apache.taglibs.standard.tag.el.core.ExpressionUtil;
+import org.apache.strutsel.taglib.utils.EvalHelper;
import org.apache.taglibs.standard.tag.common.core.NullAttributeException;
/**
@@ -150,8 +150,8 @@
ClassattrType)
throws JspException, NullAttributeException
{
-return (ExpressionUtil.evalNotNull(page, attrName, attrValue,
- attrType, this, pageContext));
+return (EvalHelper.eval(page, attrName, attrValue,
+attrType, this, pageContext));
}
/**
1.5 +7 -7
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELResourceTag.java
Index: ELResourceTag.java
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELResourceTag.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ELResourceTag.java19 Feb 2003 03:49:50 - 1.4
+++ ELResourceTag.java26 Feb 2003 06:12:25 - 1.5
@@ -62,7 +62,7 @@
import org.apache.struts.taglib.bean.ResourceTag;
import javax.servlet.jsp.JspException;
-import org.apache.taglibs.standard.tag.el.core.ExpressionUtil;
+import org.apache.strutsel.taglib.utils.EvalHelper;
import org.apache.taglibs.standard.tag.common.core.NullAttributeException;
/**
@@ -166,8 +166,8 @@
ClassattrType)
throws JspException, NullAttributeException
{
-return (ExpressionUtil.evalNotNull(resource, attrName, attrValue,
- attrType, this, pageContext));
+return (EvalHelper.eval(resource, attrName, attrValue,
+attrType, this, pageContext));
}
/**
problem with type validation
Hello, It seems to us that there is a serious flaw in the struts validation - in the RequestUtil class, the BeanUtils.populate method is called. In our testing, this allows an erroneous value to be replaced with a default value - for example a form class which will set a Short, and the form value entered is text, this will result in a value of 0. This all happens when the form bean is populated, before the server side validate() is called, or anything else can be intercepted. No exception occurs, so no errors can be generated. I was wondering if there is any idea about using something other than populate() - or making sure that the BeanUtils Converters do not use the constructors which make them enter default values has anyone else had this problem, it seems to mean struts is only good for String inputs, otherwise any type conversion is not assured? Am I missing something, is there a parameter somewhere to tell struts to do typesafe conversions? Regards, Simon ** Any personal or sensitive information contained in this email and attachments must be handled in accordance with the Victorian Information Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 (Commonwealth), as applicable. This email, including all attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute, copy or use the information contained in this email or attachments. Any confidentiality or privilege is not waived or lost because this email has been sent to you in error. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
