Re: DO NOT REPLY [Bug 39225] - In case of multilingual content the content type is not taken into account
Be warned, the tickets have moved to JIRA. The url for this ticket is http://issues.apache.org/struts/browse/STR-2823 To find a bugzilla ticket in JIRA, click on Find Issues at the top, and scroll down to the bottom where there is a text box under Custom Fields called Bugzilla Id. Enter the id then press View to find the ticket. Don [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39225. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39225 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 01:38 --- (In reply to comment #2) How about putting a filter in Jakarta Web Components, Joe? Theres one available here: http://javawebparts.sourceforge.net/ http://javawebparts.sourceforge.net/javadocs/javawebparts/filter/CharacterEncod ingFilter.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (WW-1296) Fix for broken option transfer select tag tests
[ http://issues.apache.org/struts/browse/WW-1296?page=all ] Patrick Lightbody reassigned WW-1296: - Assign To: Patrick Lightbody Fix for broken option transfer select tag tests --- Key: WW-1296 URL: http://issues.apache.org/struts/browse/WW-1296 Project: Struts Action 2 Type: Task Reporter: Bob Lee Assignee: Patrick Lightbody Attachments: brokenTest.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
Ditto... +1 along with Bob, Don, and James - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314messageID=53785#53785 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r396790 - /incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/
Author: plightbo Date: Mon Apr 24 23:57:04 2006 New Revision: 396790 URL: http://svn.apache.org/viewcvs?rev=396790view=rev Log: WW-1296: applying patch that fixes tests so they pass again Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-1.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-2.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-3.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-4.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-5.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-6.txt incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-7.txt Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-1.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-1.txt?rev=396790r1=396789r2=396790view=diff == --- incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-1.txt (original) +++ incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-1.txt Mon Apr 24 23:57:04 2006 @@ -1,7 +1,7 @@ tr td class=tdLabel/td td -script language=javascript src=/struts/optiontransferselect/optiontransferselect.js/script +script language=javascript src=/struts/optiontransferselect.js/script table border=0 tr td Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-2.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-2.txt?rev=396790r1=396789r2=396790view=diff == --- incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-2.txt (original) +++ incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-2.txt Mon Apr 24 23:57:04 2006 @@ -1,7 +1,7 @@ tr td class=tdLabel/td td -script language=javascript src=/struts/optiontransferselect/optiontransferselect.js/script +script language=javascript src=/struts/optiontransferselect.js/script table border=0 tr td Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-3.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-3.txt?rev=396790r1=396789r2=396790view=diff == --- incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-3.txt (original) +++ incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-3.txt Mon Apr 24 23:57:04 2006 @@ -1,7 +1,7 @@ tr td class=tdLabel/td td -script language=javascript src=/struts/optiontransferselect/optiontransferselect.js/script +script language=javascript src=/struts/optiontransferselect.js/script table border=0 tr td Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-4.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-4.txt?rev=396790r1=396789r2=396790view=diff == --- incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-4.txt (original) +++ incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-4.txt Mon Apr 24 23:57:04 2006 @@ -1,7 +1,7 @@ tr td class=tdLabel/td td -script language=javascript src=/struts/optiontransferselect/optiontransferselect.js/script +script language=javascript src=/struts/optiontransferselect.js/script table border=0 tr td Modified: incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-5.txt URL: http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/optiontransferselect-5.txt?rev=396790r1=396789r2=396790view=diff == ---
[jira] Resolved: (WW-1296) Fix for broken option transfer select tag tests
[ http://issues.apache.org/struts/browse/WW-1296?page=all ] Patrick Lightbody resolved WW-1296: --- Fix Version: 2.0 Resolution: Fixed Applied Fix for broken option transfer select tag tests --- Key: WW-1296 URL: http://issues.apache.org/struts/browse/WW-1296 Project: Struts Action 2 Type: Task Reporter: Bob Lee Assignee: Patrick Lightbody Fix For: 2.0 Attachments: brokenTest.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Patch for broken tests.
Applied. All the tests pass again. Thanks Bob. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27394messageID=53788#53788 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Maven build instructions...
Coming tomorrow morning. I promise :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27449messageID=53790#53790 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
+1 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314messageID=53821#53821 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On 4/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: * Proposed Change: I should mention that proposals for change are best sent to [EMAIL PROTECTED] This list is meant for people who want help using a product. Changes to the project are best discussed on [EMAIL PROTECTED] We should get back on task as to the role of each list, and :) stop annoying people who just want to know how to use the taglibs :) First, let me make clear that this proposal does NOT change the existing mechanism by which someone is invited to be a committer. That decision still rests soley with the PMC. This proposal only seeks to build on top of that mechanism. I propose that a community-based nomination process be instituted. For the sake of discussion, a qualified person is anyone that has been on the Struts Dev and/or User mailing lists for at least 6 months and has been relatively active (say, at minimum, 2 posts per week total). The main reason we make someone a committer is so that he or she can commit directly to the repository, without waiting for someone else to apply a patch. Aside from posting to the mailing list, or commenting on issue tickets, an important aspect of being active should be submitting patches that actually change the content of the repository. (Otherwise there is no practical reason for the individual to be a committer.) The tipping point for committer nominations is typically whether an individual submits useful patches. In the How to Help FAQ, we say: In an ASF project, like Apache Struts, volunteers who make sustained contributions to the project are invited to become Committers. In due course, Committers are invited to join the Project Management Committee (PMC). A goal of the ASF is for all Committers to be on the PMC. By sustained, we mean that an individual has been active in the project for at least six months. The contributions should come in the form of both patches (to code or documentation), and posts to the mailing lists. Patches must be competent and accepted into the repository. Posts must be consistently helpful, friendly, and collaborative. The most important characteristic in a prospective Committer is an amicable demeanor that fosters goodwill. * http://struts.apache.org/helping.html Any qualified person is eligible for nomination, or to nominate someone else. Naturally, a person could never nominate themselves. A nomination must then be seconded by another qualified person. At that point, a voting period of one week commences, where any non-committer and non-PMC member, qualified or not, may vote (the usual +1, 0, -1). The original nominator is responsible for tallying the vote. A person must receive at least 60% +1's (i.e., 6 out of 10 must be +1) and no more than half of the remainder may be negative. At the end of that one week period, the vote results will be posted to the Dev list and a similar one week period will commence where existing Struts team members vote for the nominee. Also note that at any point, the nominee can decline the nomination. We wouldn't want to offer someone up that doesn't want to job! Back at Jakarta, we used to have committer votes on public lists, and I saw a lot of those go very wrong. People would use them as an excuse to talk about something else. It's hard to have a candid discussion about a *person* on a public list. As it turns out, the Apache HTTPD team has never had discussions about people on a public list. I think that is a much better way to go. We announce the tallies for the committer votes that succeed, but we don't embarrass people by announcing votes and discussions that fail. Being popular on the mailing lists is a good thing. But, mailing list posts don't get us any closer to releases. As a practical matter, we need people who create code and documentation, *and* who can get along with the other committers. The committers must be a set of people who can and will do the work *and* collaborate without a lead developer or other boss pulling the strings. * Conclusion: Once again, let me make perfectly clear that the existing PMC still retains 100% control over who is invited to join. This proposal only serves to introduce a mechanism by which members of the community can be nominated and force a vote by the PMC. If you want to force a vote by the PMC, why not just bring one up on [EMAIL PROTECTED] But, please, check with the nominee first, to be sure he or she wishes to be discussed on a public list in this way. A better approach might be to send your nomination to the PMC chair and ask that it be forwarded to the PMC list. Based on votes I've seen at Jakarta and other PMC lists, the usual form is something like this: The nominee has been an active contributor to the project for more than six months. The nominee's posts to user@ and dev@ are consistently helpful. The nominee often participates in development discussions in a collaborative way. The nominee has
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
On 4/24/06, Don Brown [EMAIL PROTECTED] wrote: [x] +0 I am fine with this move, but I'll still mainly interested in 1.4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
Hi all! I wrote Retrotranslator - a tool like Retroweaver, but it supports generics and annotations at runtime, so it is even possible to run JAXB 2 on JRE 1.4: http://retrotranslator.sourceforge.net/ http://www.javalobby.org/java/forums/t66348.html Taras - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314messageID=53827#53827 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Agitator Licenses for Struts Committers
We can advertise our wares here? I did not know that. I thought this list was about Struts and not about Ted's business. But, excuse me. I should have known that Craig was not the exception in using the list that way. On 4/25/06, James Mitchell [EMAIL PROTECTED] wrote: Ok, let's review shall we. ... for our committers to use on open source projects... What part of that says anything about personal gain? -- James Mitchell On Apr 25, 2006, at 12:50 AM, Dakota Jack wrote: Isn't this using the committer status for personal gain? On 4/23/06, Ted Husted [EMAIL PROTECTED] wrote: Agitar Software (http://www.agitar.com/) has donated several licenses for its Agitator product to Apache Struts for our committers to use on open source projects. The Agitator includes experts that help it work better with frameworks like Struts Action. Right now, the Agitator Struts Expert supports Action 1.2. Experts for other releases of Apache Struts frameworks are expected. I'm working with Agitar to make the Expert API available to us, so that we can create and maintain our own experts. A whitepaper that describes using the Agitator to test the MailReader is available here: * http://www.StrutsUniversity.org/Agitator And I'll be giving the whitepaper as a webinar on Wednesday. * http://www.planetstruts.org/roller/page/news? entry=what_to_do_if_your Apache Struts committers can find the list of product keys in the ASF repository. * https://svn.apache.org/repos/private/committers/pmc/struts/ agitator-keys.txt Access to this file is resticted to Struts committers. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
+1 Leon On 4/24/06, Don Brown [EMAIL PROTECTED] wrote: There has been a lot of discussion on Java 5 support for Struts Action 2, and from my reading of the comments, we have settled on a path, but I want to formalize it in a vote to ensure we are all on the same page. I vote we develop Struts Action 2 with Java 5, taking advantage of it where ever we can. At the same time, we should use Retroweaver to build jars that will run in a 1.4 JVM. For those that aren't familiar, Retroweaver supports conversion of an impressive amount of Java 5 features and language changes. In summary, Retroweaver supports [1]: * generics * extended for loops * static imports * autoboxing/unboxing * varargs * enumerations * annotations Therefore, our development philosophy will be to take _full_ advantage of Java 5, but provide a working jar for Java 1.4, however, we can't guarantee every Struts Action 2.0 feature will be available to Java 1.4 users. -- [ ] +1 Make Java 5 the target [ ] +0 I am fine with this move, but I'll still mainly interested in 1.4 [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- I'll tally the votes after at least 72 hours and include the count in our STATUS file. The vote is open to anyone. Don [1] http://retroweaver.sourceforge.net/documentation.html - 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: Agitator Licenses for Struts Committers
You're welcome to advertise any product you like. Please prefix it with [Announce] or [Ann], but that's not required. Do you have a product you'd like to sell? -- James Mitchell On Apr 25, 2006, at 7:51 AM, Dakota Jack wrote: We can advertise our wares here? I did not know that. I thought this list was about Struts and not about Ted's business. But, excuse me. I should have known that Craig was not the exception in using the list that way. On 4/25/06, James Mitchell [EMAIL PROTECTED] wrote: Ok, let's review shall we. ... for our committers to use on open source projects... What part of that says anything about personal gain? -- James Mitchell On Apr 25, 2006, at 12:50 AM, Dakota Jack wrote: Isn't this using the committer status for personal gain? On 4/23/06, Ted Husted [EMAIL PROTECTED] wrote: Agitar Software (http://www.agitar.com/) has donated several licenses for its Agitator product to Apache Struts for our committers to use on open source projects. The Agitator includes experts that help it work better with frameworks like Struts Action. Right now, the Agitator Struts Expert supports Action 1.2. Experts for other releases of Apache Struts frameworks are expected. I'm working with Agitar to make the Expert API available to us, so that we can create and maintain our own experts. A whitepaper that describes using the Agitator to test the MailReader is available here: * http://www.StrutsUniversity.org/Agitator And I'll be giving the whitepaper as a webinar on Wednesday. * http://www.planetstruts.org/roller/page/news? entry=what_to_do_if_your Apache Struts committers can find the list of product keys in the ASF repository. * https://svn.apache.org/repos/private/committers/pmc/struts/ agitator-keys.txt Access to this file is resticted to Struts committers. -Ted. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Agitator Licenses for Struts Committers
Yep, I agree. You wouldn't believe the commission percentage that Craig gets whenever he sells a free copy of Java Studio Creator. I'm impressed that you noticed that toowow. -- James Mitchell On Apr 25, 2006, at 7:50 AM, Dakota Jack wrote: There is a big difference between having an open source project that is used for business and using your position on the list to promote your business ideas on the list. How about we begin selling our sites on this list? If you cannot see the difference in this, then you just are not being honest or you are not to bright. I think Ted sees exactly the point. Reducing this to the TV idiocy is just as bad as the usual claim that Struts is just another Apache list, which it is not. On 4/25/06, Ted Husted [EMAIL PROTECTED] wrote: On 4/25/06, James Mitchell [EMAIL PROTECTED] wrote: Ok, let's review shall we. ... for our committers to use on open source projects... What part of that says anything about personal gain? I seem to remember the term personal gain from the TV series Charmed', but I for one am not a witch :) The Apache License is designed to be business friendly. We expect and encourage commercial uses of our products. As a result, it's not uncommon for vendors of retail products to want to give back to open source projects. Another good example is JetBrains, which provides complementantry IDEA licenses to many open source projects, including the ASF. Of course, these licenses usually come with the stipulation that the license is only to be used when working on open source projects. The licenses are not for our personal use, but to help us with the volunteer work we do for the foundation. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
+1 - as this is the next version of struts I think it makes sense to make this move now. There is always webwork 2.2.2 for users that require a JDK 1.4, which will allow for the majority of the framework features and an easy stepping stone over to struts2. /Ian Don Brown wrote: There has been a lot of discussion on Java 5 support for Struts Action 2, and from my reading of the comments, we have settled on a path, but I want to formalize it in a vote to ensure we are all on the same page. I vote we develop Struts Action 2 with Java 5, taking advantage of it where ever we can. At the same time, we should use Retroweaver to build jars that will run in a 1.4 JVM. For those that aren't familiar, Retroweaver supports conversion of an impressive amount of Java 5 features and language changes. In summary, Retroweaver supports [1]: * generics * extended for loops * static imports * autoboxing/unboxing * varargs * enumerations * annotations Therefore, our development philosophy will be to take _full_ advantage of Java 5, but provide a working jar for Java 1.4, however, we can't guarantee every Struts Action 2.0 feature will be available to Java 1.4 users. -- [ ] +1 Make Java 5 the target [ ] +0 I am fine with this move, but I'll still mainly interested in 1.4 [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- I'll tally the votes after at least 72 hours and include the count in our STATUS file. The vote is open to anyone. Don [1] http://retroweaver.sourceforge.net/documentation.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
Hi, +0 . I like the java 5 features, but I can't use it right now, since the companies I work for, don't have application servers with java 5. So I am very interested to have jdk 1.4 support. I particularly don't care if all the features will not be available for jdk1.4 users :-) thanks Ricardo - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314messageID=53840#53840 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
I'm in favour of this for the reasons I put forward in response to Craig's post. I have no idea whether it will have the desired effect or not - but IMO its a good idea and I think we should give it a go. Niall On 4/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Dear Struts community, We have seen a rash of what most people consider noise on these lists recently, and I can't deny that I was even part of some of it (although I hope somewhat more constructively than some). However, underlying the noise I feel were a few valid points worth considering. I for one have. What I've come away with is a proposal I would like to make. It would represent a procedural change of sorts, or addition to be more accurate. I ask that anyone who has a thought on it please feel free to comment, but I ask that you try and do so constructively. It is not my intention to start another 200-post thread that quickly devolves into name-calling and insults. Also, please try not to get hung up on all the details, because they are debatable and negotiable (although I have tried to make them reasonable to start with). The two principles described in the conclusion are what is really important. The details of how this would work can be adjusted to make everyone happy. A proposal for community-based committer nominations * Rationale One of the issues that a number of people seem to have with the way Struts has progressed is the seeming inability (or difficulty at least) of getting new blood involved. There seems to be a perception by many that there is a bit of a closed club mentality with regard to being invited in as a committer and that the Struts community at large has no say in the matter. * Proposed Change: First, let me make clear that this proposal does NOT change the existing mechanism by which someone is invited to be a committer. That decision still rests soley with the PMC. This proposal only seeks to build on top of that mechanism. I propose that a community-based nomination process be instituted. For the sake of discussion, a qualified person is anyone that has been on the Struts Dev and/or User mailing lists for at least 6 months and has been relatively active (say, at minimum, 2 posts per week total). Any qualified person is eligible for nomination, or to nominate someone else. Naturally, a person could never nominate themselves. A nomination must then be seconded by another qualified person. At that point, a voting period of one week commences, where any non-committer and non-PMC member, qualified or not, may vote (the usual +1, 0, -1). The original nominator is responsible for tallying the vote. A person must receive at least 60% +1's (i.e., 6 out of 10 must be +1) and no more than half of the remainder may be negative. At the end of that one week period, the vote results will be posted to the Dev list and a similar one week period will commence where existing Struts team members vote for the nominee. Also note that at any point, the nominee can decline the nomination. We wouldn't want to offer someone up that doesn't want to job! * Conclusion: Once again, let me make perfectly clear that the existing PMC still retains 100% control over who is invited to join. This proposal only serves to introduce a mechanism by which members of the community can be nominated and force a vote by the PMC. That is of course the first important principle of this proposal. The other important principle is taking the will of the community into account. By having the PMC not vote until AFTER the community has voted, the will of the community should be apparent, and the idea is that the PMC will take that into account when voting. The community will then have a clear indication whether they have been listened to or not based on the outcome of the vote (and the comments made during the vote because, after all, there ould be legitimate reasons not to adhere to the community's vote, and hose reasons should come out in discussion). But, at the end of the day, who is invited to join is still decided by the PMC, as it is today. I look forward to feedback. Thanks for listening! Frank - 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: .NET/WebServices/Java
Ted, My boss is running it by the lawyers. I will keep you posted, and keep working on the framework. Thanks and regards, John On 4/25/06, Ted Husted [EMAIL PROTECTED] wrote: It would be better to continue the thread on dev@struts.apache.org, but there's no reason to take the discussion off list. -Ted. On 4/24/06, John B. Walker [EMAIL PROTECTED] wrote: Thanks Ted! I will dust off my old sourceforge.net account and take this conversation off the user group with you personally. I appreciate the help. It's people like you that make it easy for developers to come into the Open Dev community. Thanks again, John On 4/23/06, Ted Husted [EMAIL PROTECTED] wrote: On 4/23/06, John B. Walker [EMAIL PROTECTED] wrote: My next question for you Ted (or others), is: How would I contribute this source back to Struts, and do you think that the committee would be interested in adopting this framework into the Struts project? The first step would be to get the code out there where people can try it. This can simply be a matter of setting up a home page that describes the product with a link to download the package. A very good way to get started is to setup a Java.net or Sourceforge.net project. If you don't want to start your own project, there is a Struts SourceForge project (struts.sf.net) where you could upload the code. Just take out a SourceForge account and let me know what your user id, and a working name for the product, and I'll setup a module for you, In general, the ASF isn't interested in donations of code that do not include a community of developers who are ready, willing, and able to maintain the code. The ASF has no paid staff, so we have to be sure that there are volunteers to do the work. The first step is finding volunteers to help with an open source project is to publish the source :) HTH, Ted.
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
-- [ ] +1 Make Java 5 the target ' +1 - Erik
Re: Proposal for change
On Tue, April 25, 2006 1:17 am, Craig McClanahan said: The latter statement is, as mentioned in my previous response, the way that *all* projects at Apache work -- it is not unique to Struts. Any claim that all of Apache is broken in this regard is going to be, umm, unlikely to be agreed with :-). What's more interesting is to examine the former statement, and compare it to the facts. Please don't infer the word broken, I never used it :) Broken has a negative connotation. I'm talking about an improvement. Unless you believe the way things are today is 100% perfect, then there is always room for improvement. Something doesn't have to be broken for a change to be reasonable. Also, I'm not talking about all of Apache here, I'm talking only about Struts. Granted I'm not a member of every community at Apache, but of the ones I am (even as just a lurker), Struts seems to be the only one that evokes these types of criticisms (rightly or wrongly so). I'm not suggesting trying to change the way all of Apache works, and in fact, I'm not trying to change the way Struts works. Just build on top of it a little bit. If this idea were to work, and other projects saw and liked it, maybe it would change all of Apache eventually. That's not one of my goals here today :) That is a pretty large percentage increase for a single year, even discounting the merger -- and have you ever seen other competing communities come together like this? Hmm ... doesn't seem like the existing community is particularly closed to new blood to me. That depends entirely on your meaning of the word closed. You make the argument that the number of new committers means it isn't closed, and I agree with you to a degree. But that's not the only meaning of closed... the invitations to those people came *soley* from the PMC AFAIK... the community had no say in it. That's the thing my proposal seeks to address, that the initiation of someone being invited doesn't necessarily have to come from those already there (although they would still have the final say-so). Examining how the new folks got themselves nominated and elected is also interesting. In every case, it was based on continuous contributions of code, documentation, user list help, build script maintenance, or whatever made a *positive* difference for everyone. That's the way it *should* work, but I don't believe it is the way it *has* worked. There are a number of other names that would have been invited as well if that is all there was to it. My proposal seeks to remove that something else... no, actually, it doesn't seek to remove it, it only seeks to bring it into the light, so to speak. If someone were nominated and ultimately not invited to join, the community could look and see if they believed that person met the criteria you list above. If they did and still were not invited, it would be obvious that something else was at work. Perhaps it was something completely legitimate; it probably would come out in discussion during the vote period then. Maybe it isn't something legitimate (as judged by the community). Either way, we'd know, and could form our opinions accordingly. There is also another interesting observation here -- you don't have to be a committer to initiate changes to the Struts code base. What you have to do is justify your bugfix or RFE to the point where an existing committer is willing to take responsibility for cleaning up any messes that committing the change might cause. So, you only have to convince one of the various folks to get your patch in. Failure to succeed in that goal *could* be a close minded community, but it also just might be that the proposed change doesn't fit with what the committers as a whole have in mind (it only takes one commiter -1 to make a committed change get reversed, so we pay attention to this as part of the decision process on accepting a patch). Just in the little time I have had to spend on Struts in the last year, I've committed patches from at least 20 different people. Spread across the six years that Struts has existed, and all the committers who have done the same thing, we are talking many *hundreds* of people who have contributed at least some code or documentation to what is now Struts. Perfectly fair observation IMO. I just don't buy the presumption that the current system is broken. I won't presume to convince *you* to think that way -- it's your perogative to think whatever you want -- but I will certainly take into account whether someone gets it before I would ever vote for them to be a committer. Again, I never said anything was broke. If I were to describe it, I would probably say sub-optimal. Unless you are prepared to say that you think everything is absolutely perfect just the way it is, then there is *always* remove for improvement, it doesn't have to be broken. The getting it comment... if this equates to you have to see things
Re: Proposal for change
On Tue, April 25, 2006 12:36 am, Craig McClanahan said: Without commenting on the merit of the proposal itself, or the reasoning presented as its justification, it is important to note that we (the Struts community) do not have free reign to do whatever we want in this regard. As part of Apache, the Struts community is accountable to the Apache Software Foundation's Board of Directors, and one of the things that gets watched is how well the various projects implement the Apache Way. And one of the key tenets of that way is how new committers get selected. I understand that... does that mean that a particular project is not allowed to try something new? If there are rules in place to keep projects from donig so, then I wasn't aware of that, and certainly that puts a damper on this proposal :) Regardless of the details, anything along the general lines of what you describe would be quite different from the way Apache has grown from the very beginning to what it is today -- and it would, therefore, be looked at with a *lot* of skepticism by Apache as a whole. I would *hope* it would be looked upon with skepticism :) I'm certainly in no way saying the Apache Way hasn't worked all this time, of course it has! :) But, is skepticism enough to dissuage an attempt at something? Assuming there are no rules in place to stop a project from trying it I mean. Trying to argue that the Apache Way is flawed, and needs to be fundamentally changed like this, does not seem likely (to me) to get much agreement Apache wide, given the ASF's history, and the success of many of its projects at building communities of committers that buy in to that culture -- and, by the way, produce some pretty popular software to boot. No argument. But again, I'm not talking about changing anything Apache-wide. I'm talking about trying something in one project where there *seems* to be a perception that things could be somewhat improved, and seeing how it works. So what the heck is this Apache way thing? It is a culture; a way of gathering a community that interoperates ... and it can be tough at times to write down a descrption that makes sense. But [1] is a pretty good starting point. I'd also recommend looking through the documentation for the Incubator Project (where a specific exit criteria is that the folks participating in the new project get it about the Apache way). Frank Craig [1] http://www.apache.org/foundation/how-it-works.html I've read this page before, and just did so again. While I think it is fantastic at describing what Apache is and how it works, I don't see anything that would help me or anyone else understand how to get it. Aside from the discussion on meritocracy, nothing seems to discuss that. The Philosophy section seems to discuss the philosophy of a project, the the philosophy of how someone needs to conduct themselves to get it. I would very much like to understand how this determination is made. PS: If you like the code but don't like the community, one of the best things about Apache is that the license gives you the right to fork and build your own community, operated according to whatever rules please you. So, even if a proposal like this is not accepted, you still have the opportunity to go build a better Struts -- that doesn't have to be done here. You are of course right about this. But, much like taking the ideas about inventory control and order processing and such from Dell and starting your own business is possible, the likelihood that you would get anything but a small fraction of the attention and business that Dell gets is slim to none. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On Tue, April 25, 2006 6:45 am, Ted Husted said: I should mention that proposals for change are best sent to [EMAIL PROTECTED] This list is meant for people who want help using a product. Changes to the project are best discussed on [EMAIL PROTECTED] We should get back on task as to the role of each list, and :) stop annoying people who just want to know how to use the taglibs :) Yes, I considered doing that... but as my proposal was specifically *for* the community, I felt it important to put the most number of eyeballs on it as possible. You know, perhaps we need *three* mailing lists... one for devs, one for users who just want questions answered, and one for the community, those that want to be involved in shaping things but that aren't committers. :) Back at Jakarta, we used to have committer votes on public lists, and I saw a lot of those go very wrong. People would use them as an excuse to talk about something else. It's hard to have a candid discussion about a *person* on a public list. As it turns out, the Apache HTTPD team has never had discussions about people on a public list. I think that is a much better way to go. We announce the tallies for the committer votes that succeed, but we don't embarrass people by announcing votes and discussions that fail. I certainly see the point your making, I happen to agree with it. Perhaps it should work more like a senate confirmation hearing in the sense that before you begin to discuss someone you ask them if they want to be considered, and then have the discussions in public? (I think Niall more or less suggests the same thing in this thread). If a person accepts a nomination, they then accept the public debate, and any embarassment that might result. Just a thought. If you want to force a vote by the PMC, why not just bring one up on [EMAIL PROTECTED] But, please, check with the nominee first, to be sure he or she wishes to be discussed on a public list in this way. I didn't frankly know that was an option... has that ever happened before? If there is some unofficial policy in this regard, I'd be happy to know about it... as long as there is some unwritten rule that the PMC will vote on a nominee made by someone not on the PMC, then the underlying spirit of my proposal is already in place... I think it's always better to codify these kinds of things, but I can live with an unwritten rule :) I'd like to know that it has been exercised in the past though. From an ASF perspective, the community is not everyone who subscribes to the mailing list and downloads the product. The community is the set of individuals who contribute to the project, both by making helpful posts to the mailing list *and* by contributing useful code and documentation. Downloads don't make the product possible. Contributions make the product possible. Our customers are the contributors, who pay for the product with posts and patches. I guess this is one way that I've never quite got it, as Craig says :) I view the community as being larger than just those contributing. While I have no problem affording something more to those that contribute, I think those simply using the product have a stake in it. They can of course choose to ignore that stake, but they can exercise interest if they wish. For me, the community would be anyone who has an active interest in how the project develops. Those that contribute in some way deserve a louder voice and a bigger say in things, but I don't think contributing is the only criteria for being in the community. But that is my interpretation, I realize it doesn't jive with the ASF interpretation :) Over the years, I think there have been exactly two committer nominations here that failed, and both times the failed nominees had not submitted a single patch. Question: does submitting a patch have to mean having the patch accepted? At first glance, the obvious answer is yes, but I'm not so sure it's really the obvious answer... if someone has submitted a number of patches that were not committed for reasons other than purely technical (i.e., the patch will break X), should those patches be considered? But, at the end of the day, who is invited to join is still decided by the PMC, as it is today. :) Well, yeah. We're the ones that have to live with the decision, long after whoever voted on the nomiantion might have unsubscribed and faded away. :) Yep :) Who I would feel sorry for is all the people who might be nominated, and then turned down, on a public list, without ever even asking to be nominated or discussed in a public forum. This isn't about making legislation or winning a popularity contest. We need people who *can and do* create code or documentation and *collaborate* with other team members, without a suit or lead developer pulling the strings. Yes, that's why I'm not completely against the private system in place now. I do agree with your point here. As I suggested
Re: [action2] Patch for broken tests.
Thanks Bob...we need to get a CI server up so I get my wrist slapped sooner ;) Don Bob Lee wrote: http://issues.apache.org/struts/browse/WW-1296 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Java 1.4 support libraries (was [VOTE] Target Java 5, support 1.4 through Retroweaver)
This is good to know, as I'd hate for our 1.4 strategy to be dependent on a single tool. I'm especially interested in your support for annotations, as AFAICT, that is a feature missing from Retroweaver. Could you post a snippet that shows how annotations would work in 1.4? My view is the vote is more about a strategy to support 1.4, and less about the actual tool Retroweaver. If it turns out Retrotranslater does more of what we want and is better supported, I think it should be seriously considered. Don Taras Puchko wrote: Hi all! I wrote Retrotranslator - a tool like Retroweaver, but it supports generics and annotations at runtime, so it is even possible to run JAXB 2 on JRE 1.4: http://retrotranslator.sourceforge.net/ http://www.javalobby.org/java/forums/t66348.html Taras - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314messageID=53827#53827 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WW-1259) ww:head tag in ajax theme causes secure/non-secure content prompt in IE
[ http://issues.apache.org/struts/browse/WW-1259?page=comments#action_37183 ] Patrick Lightbody commented on WW-1259: --- I had this same problem. The fix described here solved it: http://permalink.gmane.org/gmane.comp.web.dojo.user/5871 ww:head tag in ajax theme causes secure/non-secure content prompt in IE - Key: WW-1259 URL: http://issues.apache.org/struts/browse/WW-1259 Project: Struts Action 2 Type: Bug Versions: WW 2.2 Reporter: Jason Jones Assignee: Ian Roughley Fix For: 2.0 See http://forums.opensymphony.com/thread.jspa?threadID=23032 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
Hey there, I would like to see Struts Action 2 support Java 5 as the default platform, so +1 from me. If Retroweaver and/or Retrotranslater provide full support for Java 5 language extensions we should definately use it/them to have a Java 1.4 compliant version as well. Haven't looked at those projects deeply enough to say if this will be possible, but we should investigate this approach. One thing we need to keep in mind is that xwork does not depend on Java 5 for now. So if we decide to base SAF 2 on Java 5, we need a Java 5 version of xwork as well. As a xwork developer I would volunteer for this task (xwork 2.0?). Currently Java 5 support in xwork is realized as an addon project (xwork-tiger). However, this needs a lot more attention, there are several tasks open to be done. regards, Rainer On Apr 24, 2006, at 22:24 , Don Brown wrote: There has been a lot of discussion on Java 5 support for Struts Action 2, and from my reading of the comments, we have settled on a path, but I want to formalize it in a vote to ensure we are all on the same page. I vote we develop Struts Action 2 with Java 5, taking advantage of it where ever we can. At the same time, we should use Retroweaver to build jars that will run in a 1.4 JVM. For those that aren't familiar, Retroweaver supports conversion of an impressive amount of Java 5 features and language changes. In summary, Retroweaver supports [1]: * generics * extended for loops * static imports * autoboxing/unboxing * varargs * enumerations * annotations Therefore, our development philosophy will be to take _full_ advantage of Java 5, but provide a working jar for Java 1.4, however, we can't guarantee every Struts Action 2.0 feature will be available to Java 1.4 users. -- [ ] +1 Make Java 5 the target [ ] +0 I am fine with this move, but I'll still mainly interested in 1.4 [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- I'll tally the votes after at least 72 hours and include the count in our STATUS file. The vote is open to anyone. Don [1] http://retroweaver.sourceforge.net/documentation.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On Apr 25, 2006, at 9:55 AM, Frank W. Zammetti wrote: That depends entirely on your meaning of the word closed. You make the argument that the number of new committers means it isn't closed, and I agree with you to a degree. But that's not the only meaning of closed... the invitations to those people came *soley* from the PMC AFAIK... the community had no say in it. That's the thing my proposal seeks to address, that the initiation of someone being invited doesn't necessarily have to come from those already there (although they would still have the final say-so). I have some serious concerns about this. Let me just use myself as an example. I've been a committer for about 6 months or so. I have absolutely no idea what sort of discussion took place before I received that invitation. If there was someone among the PMC who was vehemently opposed to my nomination I'm glad they had a confidential forum in which to discuss their concerns. Now that I am a committer I can have an unbiased conversation with anybody else in the group without any preconceived notion of what that individual's opinion of me might be. Truly, I don't have confidence that either user@ or dev@ is a place where concerns can be expressed openly without fear of unprofessional response. It's just too easy for this kind of discussion to turn into personal attacks in a forum such as user@ or even [EMAIL PROTECTED] When Struts was a Jakarta subproject I remember committer votes taking place on [EMAIL PROTECTED] I always felt just a little uneasy about it. 99 times out of 100 it was a unanimous +1 with no discussion. But I seem to recall at least one case when concerns were expressed (sorry, I don't remember the specifics, please correct me if I'm wrong). I feel really bad that this person's personal merit would have to be discussed in a public forum. I understand some others' concerns about the community appearing to be closed, but I think there should be a barrier to entry. Maybe it's too high, but it seems to me that it should exist. After all it's basically a lifetime appointment and revocations are very rare if one has ever happened at all. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
Frank W. Zammetti wrote: You are of course right about this. But, much like taking the ideas about inventory control and order processing and such from Dell and starting your own business is possible, the likelihood that you would get anything but a small fraction of the attention and business that Dell gets is slim to none. Not to sidle in where I don't really belong but perhaps this last sentence exemplifies the disconnect with getting it? If one wanted to take the code from an apache project and do something else with it then all they care about is the something else they want to do. It isn't really a business... the code exists for the code's sake. I'm not a committer but I've been following this list and the tomcat dev list since the last millennium... I think before there even was a struts 1.0. I can't speak in an official capacity, I can't even pretend, but here is my take on the apache way. For an open source project to exist you need code. All of apache projects seem to exist to benefit the code... and by extension the documentation. Though, even without documentation you still have the code. All of the other stuff is extraneous or the life support system depending on how you look at it. I think most of the apache way is partially considering it to be extraneous... in a if the code goes sour and you have nothing sort of way. It's definitely symbiotic but without the code, you have nothing. You might as well be chatting on myspace.com. So, the only reason to be a committer is to contribute to the codebase... and all other committers have to live with each other. The only reason to be able to cast a binding vote is if you have a stake in the code... ie: are a committer. Which doesn't mean that other votes don't count... that's up to how the committers want to appeal to the community. But ultimately, they have to live with what the decide so it makes sense that they have the final word. Bottom line: if a person isn't contributing to code and documentation in a way that the other committers are comfortable with then that person shouldn't be a committer on the project. There is no other reason for being a committer. My personal (and probably unneeded) opinion on the original subject: From my perspective, nominations don't matter so much... as I recall someone could nominate themselves. If that person hasn't been contributing code then there is no reason to think they will become a committer. It would be nice if the process were a little more transparent as it would be interesting to know who was proposed, accepted, rejected, etc. even if we didn't know why. (Though, even counter to that it was nice to know that someone who contributed to another apache project and stomped all over my contributed implementation because they didn't bother to patch to head was at least a controversial nomination. But that's sort of personal and isolated reason for wanting to see the dirty laundry.) I guess I have trouble seeing how things could be improved much by your proposal... especially since I understood there to be nothing wrong with nominations coming from anywhere. It was just explained to be easier with a committer's support. I don't follow this list too closely, so maybe I missed someone who has been contributing lots of stuff and still was overlooked. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On 4/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: * Rationale One of the issues that a number of people seem to have with the way Struts has progressed is the seeming inability (or difficulty at least) of getting new blood involved. There seems to be a perception by many that there is a bit of a closed club mentality with regard to being invited in as a committer and that the Struts community at large has no say in the matter. Having composed a nice long response, I can now delete it, since Craig says below pretty much everything I was going to say also. ;-) One thing I'll add, though. The problem appears to be perception, and reality doesn't, in my opinion and as evidenced below, match that perception. Therefore the solution should be addressing the _perception_ of the way Struts is working, and changing perception does not require changes to the _reality_ of the way it's working. And one question I would ask: What, exactly, is the end goal? More committers? More nominations? If bringing in a new committer every other month, as we've been doing, isn't enough, what is? As other people have pointed out elsewhere, more committers doesn't necessarily translate to more activity on the code base, either, as we've seen in the past. On the topic of voting in public, I am very much opposed. It's not just a case of saving face for a nominee who is ultimately rejected. A public vote affects the way people vote, as well. In a private vote, someone might object strongly, along the lines of -1 - that guy's code is a pile of crap. But would the same person voice that same opinion in a public vote on a mailing list of a couple of thousand people, and which will be archived for the world to see, forever? Perhaps a few would, but many would not. They would more likely keep quiet, the end result being that Mr. Pile O'Crap becomes a committer because the only people who voted were the ones in favour. IMHO, that is A Very Bad Thing. -- Martin Cooper The latter statement is, as mentioned in my previous response, the way that *all* projects at Apache work -- it is not unique to Struts. Any claim that all of Apache is broken in this regard is going to be, umm, unlikely to be agreed with :-). What's more interesting is to examine the former statement, and compare it to the facts. The Who We Are page[1] lists the current folks who are on the PMC (and also have committer privileges), and who are committers not on the PMC. There's 14 and 13 names, respectively, giving a total of 27 (and this doesn't count the 10 previous committers who are now on the emeritus list, for a total of 37). That's a pretty good size number, compared to the average at Apache. But what is really interesting is to look at the timing of how we got from one committer (me) six years ago, to where we are today -- and focus especially on the more recent changes. In just the last year there have been quite a number of new committers added[2] ... six independent of the WebWork merger (Wendy, Gary, Greg, Shawn, Laurie, and Richard), two more (Jason and Patrick) directly because of the merger, and five more who have commit rights to the WebWork incubator code and will become Struts committers as soon as it graduates. There is also one outstanding invitation that, for personal reasons fo the individual involved, will be accepted later rather than now. That is a pretty large percentage increase for a single year, even discounting the merger -- and have you ever seen other competing communities come together like this? Hmm ... doesn't seem like the existing community is particularly closed to new blood to me. Examining how the new folks got themselves nominated and elected is also interesting. In every case, it was based on continuous contributions of code, documentation, user list help, build script maintenance, or whatever made a *positive* difference for everyone. Indeed, if you go back to the days when folks like Ted and Martin were added, a lot of it was being tired of applying all the patches they were contributing :-). All of these folks get it -- so it is not just a couple of dictatorial snobs sitting on top of the mountain dictating who is in and who is out :-). There is also another interesting observation here -- you don't have to be a committer to initiate changes to the Struts code base. What you have to do is justify your bugfix or RFE to the point where an existing committer is willing to take responsibility for cleaning up any messes that committing the change might cause. So, you only have to convince one of the various folks to get your patch in. Failure to succeed in that goal *could* be a close minded community, but it also just might be that the proposed change doesn't fit with what the committers as a whole have in mind (it only takes one commiter -1 to make a committed change get reversed, so we
Re: Proposal for change
On 4/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Yes, I considered doing that... but as my proposal was specifically *for* the community, I felt it important to put the most number of eyeballs on it as possible. You know, perhaps we need *three* mailing lists... one for devs, one for users who just want questions answered, and one for the community, those that want to be involved in shaping things but that aren't committers. :) [...] I guess this is one way that I've never quite got it, as Craig says :) I view the community as being larger than just those contributing. While I have no problem affording something more to those that contribute, I think those simply using the product have a stake in it. They can of course choose to ignore that stake, but they can exercise interest if they wish. For me, the community would be anyone who has an active interest in how the project develops. There! You've said it. That exactly describes the purpose of the dev@ list. So, now, why again do we need the three lists you mention above? ;-) -- Martin Cooper
[jira] Closed: (STR-2742) Validation always skipped with Globals.CANCEL_KEY
[ http://issues.apache.org/struts/browse/STR-2742?page=all ] Don Brown closed STR-2742: -- Fix Version: 1.2.9 Resolution: Fixed Assign To: (was: Struts Developer Mailing List) Closing as it has been several weeks. If you are still having a problem, please open a new ticket. Validation always skipped with Globals.CANCEL_KEY - Key: STR-2742 URL: http://issues.apache.org/struts/browse/STR-2742 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.2.8 Environment: Operating System: other Platform: Other Reporter: Paul Benedict Fix For: 1.2.9 Attachments: InvalidCancelException.java, UnsupportedCancellationException.java, ValidateCancelable.txt, ValidateCancelable.txt, cancellable.txt, patch.txt, rp13-patch.txt * Issue: addition of a 'org.apache.struts.taglib.html.Constants.CANCEL' parameter to any request will cause validation to be skipped, but the rest of the request processing / action invocation cycle to proceed normally * Consequence: any action which proceeds assuming that validation has completed successfully and which doesn't explicitly check isCanceled() is proceeding on a broken assumption. The discussion of this issue began in the struts-user list: http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL PROTECTED] The thread continued in struts-dev list: http://mail-archives.apache.org/mod_mbox/struts-dev/200601.mbox/[EMAIL PROTECTED] Most people have agreed that this is a security-related issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1798) Enhanced performance for TagUtils.filter()
[ http://issues.apache.org/struts/browse/STR-1798?page=all ] David Evans reopened STR-1798: -- Assign To: David Evans (was: Struts Developer Mailing List) Enhanced performance for TagUtils.filter() -- Key: STR-1798 URL: http://issues.apache.org/struts/browse/STR-1798 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: Nightly Build Environment: Operating System: All Platform: All Reporter: Sean Owen Assignee: David Evans Priority: Minor Fix For: 1.2 Family Attachments: TagUtils.patchfile.txt, TestTagUtils.java, build-tests.xml.patchfile.txt The TagUtils.filter() method, which replaces certain characters with corresponding XML entity references, can be easily enhanced to run much faster and require less memory. To summarize it can be made faster in two ways: * Instead of building up the escape string character by character, with a call to StringBuffer.append() for each character, it can be rewritten to copy chunks of input at a time, avoiding many method calls, which is most of the overhead of this method. * In fact the method does not even need to allocate a StringBuffer until it knows that some character in the input must be escaped. In the common case where the input has no such characters, this avoids allocating any additional memory at all. Performance improvements is large when the string has no characters to be escaped -- 1000% or more on the small and medium-sized strings I tested on. It offers more modest improvement when the string has some escapable characters -- 50-100% on small and medium-sized strings. It is only slower in contrived cases like . While it is a small method, it is called many times by the Struts framework. This is an easy and reliable change to squeeze out a little better performance in time and memory for all applications. Note that I created a JUnit test for this change (included) in order to verify that the new method works as well as the current one. Please find attached files which implement this enhancement: * TagUtils.patchfile.txt Patch against the 10/19/2003 nightly build to implement the change to filter() * TestTagUtils A new JUnit test case covering the filter() method * build-test.xml.patchfile.txt Patch against the 10/19/2003 build-test.xml file to invoke TestTagUtils I posted this change to the list once before with no result -- I hope this even better version, with unit test this time, can be considered for inclusion in Struts -- thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1798) Enhanced performance for TagUtils.filter()
[ http://issues.apache.org/struts/browse/STR-1798?page=all ] David Evans closed STR-1798: Resolution: Fixed Enhanced performance for TagUtils.filter() -- Key: STR-1798 URL: http://issues.apache.org/struts/browse/STR-1798 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: Nightly Build Environment: Operating System: All Platform: All Reporter: Sean Owen Assignee: David Evans Priority: Minor Fix For: 1.2 Family Attachments: TagUtils.patchfile.txt, TestTagUtils.java, build-tests.xml.patchfile.txt The TagUtils.filter() method, which replaces certain characters with corresponding XML entity references, can be easily enhanced to run much faster and require less memory. To summarize it can be made faster in two ways: * Instead of building up the escape string character by character, with a call to StringBuffer.append() for each character, it can be rewritten to copy chunks of input at a time, avoiding many method calls, which is most of the overhead of this method. * In fact the method does not even need to allocate a StringBuffer until it knows that some character in the input must be escaped. In the common case where the input has no such characters, this avoids allocating any additional memory at all. Performance improvements is large when the string has no characters to be escaped -- 1000% or more on the small and medium-sized strings I tested on. It offers more modest improvement when the string has some escapable characters -- 50-100% on small and medium-sized strings. It is only slower in contrived cases like . While it is a small method, it is called many times by the Struts framework. This is an easy and reliable change to squeeze out a little better performance in time and memory for all applications. Note that I created a JUnit test for this change (included) in order to verify that the new method works as well as the current one. Please find attached files which implement this enhancement: * TagUtils.patchfile.txt Patch against the 10/19/2003 nightly build to implement the change to filter() * TestTagUtils A new JUnit test case covering the filter() method * build-test.xml.patchfile.txt Patch against the 10/19/2003 build-test.xml file to invoke TestTagUtils I posted this change to the list once before with no result -- I hope this even better version, with unit test this time, can be considered for inclusion in Struts -- thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1762) 'integer' rule doesn't work properly with indexed properties
[ http://issues.apache.org/struts/browse/STR-1762?page=all ] David Evans reopened STR-1762: -- Assign To: David Evans (was: Struts Developer Mailing List) 'integer' rule doesn't work properly with indexed properties Key: STR-1762 URL: http://issues.apache.org/struts/browse/STR-1762 Project: Struts Action 1 Type: Bug Components: Action Versions: Nightly Build Environment: Operating System: Windows XP Platform: PC Reporter: Jim Prantzalos Assignee: David Evans Fix For: 1.2 Family I have the following rule in validation.xml: field property=x indexedListProperty=coords depends=integer arg0 key=xyzForm.xcoord.label/ /field .. and I have a form that accepts 3 rows of x,y,z coords. If I enter the values: X: K Y: 2 Z: 3 X: Y: 5 Z: 6 X: 7 Y: 8 Z: 9 I will get a message that says 'X-coordinate must be an integer.' as expected. However, if I enter: X: Y: 2 Z: 3 X: K Y: 5 Z: 6 X: K Y: 8 Z: 9 .. where X[0] is empty, then it accepts this as valid input. I appears as if the validator does not bother to check the remaining indexes once it hits an empty index. For example, the following will detect a validation error: X: 9 Y: 2 Z: 3 X: K Y: 5 Z: 6 X: 7 Y: 8 Z: 9 and the following will not (as expected): X: 9 Y: 2 Z: 3 X: 4 Y: 5 Z: 6 X: Y: 8 Z: 9 but the following will not flag a validation error, and it should: X: 1 Y: 2 Z: 3 X: Y: 5 Z: 6 X: K Y: 8 Z: 9 I hope I've been able to clearly define the problem. Please email me if you have further questions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1762) 'integer' rule doesn't work properly with indexed properties
[ http://issues.apache.org/struts/browse/STR-1762?page=all ] David Evans closed STR-1762: Resolution: Fixed 'integer' rule doesn't work properly with indexed properties Key: STR-1762 URL: http://issues.apache.org/struts/browse/STR-1762 Project: Struts Action 1 Type: Bug Components: Action Versions: Nightly Build Environment: Operating System: Windows XP Platform: PC Reporter: Jim Prantzalos Assignee: David Evans Fix For: 1.2 Family I have the following rule in validation.xml: field property=x indexedListProperty=coords depends=integer arg0 key=xyzForm.xcoord.label/ /field .. and I have a form that accepts 3 rows of x,y,z coords. If I enter the values: X: K Y: 2 Z: 3 X: Y: 5 Z: 6 X: 7 Y: 8 Z: 9 I will get a message that says 'X-coordinate must be an integer.' as expected. However, if I enter: X: Y: 2 Z: 3 X: K Y: 5 Z: 6 X: K Y: 8 Z: 9 .. where X[0] is empty, then it accepts this as valid input. I appears as if the validator does not bother to check the remaining indexes once it hits an empty index. For example, the following will detect a validation error: X: 9 Y: 2 Z: 3 X: K Y: 5 Z: 6 X: 7 Y: 8 Z: 9 and the following will not (as expected): X: 9 Y: 2 Z: 3 X: 4 Y: 5 Z: 6 X: Y: 8 Z: 9 but the following will not flag a validation error, and it should: X: 1 Y: 2 Z: 3 X: Y: 5 Z: 6 X: K Y: 8 Z: 9 I hope I've been able to clearly define the problem. Please email me if you have further questions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1758) In struts-validator example, formset lacks some form definitions.
[ http://issues.apache.org/struts/browse/STR-1758?page=all ] David Evans reopened STR-1758: -- Assign To: David Evans (was: Struts Developer Mailing List) In struts-validator example, formset lacks some form definitions. - Key: STR-1758 URL: http://issues.apache.org/struts/browse/STR-1758 Project: Struts Action 1 Type: Bug Components: Apps Versions: Nightly Build Environment: Operating System: other Platform: Other Reporter: Takayoshi Kimura Assignee: David Evans Priority: Minor Attachments: patch In struts-validator example, formset that has fr_CA locales lacks some form definitions. If you choose French Canadian and multiRegistration1.jsp (or jsRegistration.jsp), you will get a broken Javascripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-667) Validator Range Checking Bug
[ http://issues.apache.org/struts/browse/STR-667?page=all ] Don Brown closed STR-667: - Resolution: Fixed Validator Range Checking Bug Key: STR-667 URL: http://issues.apache.org/struts/browse/STR-667 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: other Platform: Other Reporter: James Farley Priority: Blocker Fix For: 1.1 Family Attachments: validator-rules.xml.diff Currently, the struts validation framework allows you to validate based on any number of dependencies, among them: float, double, mask, range, etc. In my validation.xml file I have a parameter that I am attempting to validate based on three dependencies: required,mask,float,range. I would like a user to be able to enter a dollar amount in the format 00.00 and have the value be in the range 0 to 99. Everything works perfectly *except* for the range dependency, as this dependency assumes that the number that you are validating against is an integer. To me, this seems inappropriate. I should be able to validate any numerical range, including floating point numbers. I looked through the source code and it looks like two modifications would need to be made to change this: one to the org.apache.struts.util.StrutsValidator.validateRange() method and one to the org.apache.commons.validator.GenericValidator.isInRange() method. To me, the methods should perform validation on the most generic case (a double). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-667) Validator Range Checking Bug
[ http://issues.apache.org/struts/browse/STR-667?page=all ] Don Brown reopened STR-667: --- Assign To: (was: Struts Developer Mailing List) Validator Range Checking Bug Key: STR-667 URL: http://issues.apache.org/struts/browse/STR-667 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: other Platform: Other Reporter: James Farley Priority: Blocker Fix For: 1.1 Family Attachments: validator-rules.xml.diff Currently, the struts validation framework allows you to validate based on any number of dependencies, among them: float, double, mask, range, etc. In my validation.xml file I have a parameter that I am attempting to validate based on three dependencies: required,mask,float,range. I would like a user to be able to enter a dollar amount in the format 00.00 and have the value be in the range 0 to 99. Everything works perfectly *except* for the range dependency, as this dependency assumes that the number that you are validating against is an integer. To me, this seems inappropriate. I should be able to validate any numerical range, including floating point numbers. I looked through the source code and it looks like two modifications would need to be made to change this: one to the org.apache.struts.util.StrutsValidator.validateRange() method and one to the org.apache.commons.validator.GenericValidator.isInRange() method. To me, the methods should perform validation on the most generic case (a double). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-236) ActionForm.validate method fails with multipart request
[ http://issues.apache.org/struts/browse/STR-236?page=all ] Don Brown reopened STR-236: --- Assign To: (was: Mike Schachter) ActionForm.validate method fails with multipart request --- Key: STR-236 URL: http://issues.apache.org/struts/browse/STR-236 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 3 Environment: Operating System: All Platform: Other Reporter: graemem Priority: Critical Fix For: 1.0.0 Problem: The validate(mapping, request) method on the ActionForm class is not completing sucessfully in Struts 1.0b3 where it was in Struts 1.0b1. Detail: This is a multipart form that has a couple of struts file upload controls on it (as well as text fields etc) so I suppose that might be related somehow. The exception being thrown in the log is :- java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:144) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:21 37) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java, Compiled Code) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code) at java.lang.Thread.run(Thread.java:479) This worked fine under Struts 1.0b1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1758) In struts-validator example, formset lacks some form definitions.
[ http://issues.apache.org/struts/browse/STR-1758?page=all ] David Evans closed STR-1758: Resolution: Fixed In struts-validator example, formset lacks some form definitions. - Key: STR-1758 URL: http://issues.apache.org/struts/browse/STR-1758 Project: Struts Action 1 Type: Bug Components: Apps Versions: Nightly Build Environment: Operating System: other Platform: Other Reporter: Takayoshi Kimura Assignee: David Evans Priority: Minor Attachments: patch In struts-validator example, formset that has fr_CA locales lacks some form definitions. If you choose French Canadian and multiRegistration1.jsp (or jsRegistration.jsp), you will get a broken Javascripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-236) ActionForm.validate method fails with multipart request
[ http://issues.apache.org/struts/browse/STR-236?page=all ] Don Brown closed STR-236: - Resolution: Fixed ActionForm.validate method fails with multipart request --- Key: STR-236 URL: http://issues.apache.org/struts/browse/STR-236 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 3 Environment: Operating System: All Platform: Other Reporter: graemem Priority: Critical Fix For: 1.0.0 Problem: The validate(mapping, request) method on the ActionForm class is not completing sucessfully in Struts 1.0b3 where it was in Struts 1.0b1. Detail: This is a multipart form that has a couple of struts file upload controls on it (as well as text fields etc) so I suppose that might be related somehow. The exception being thrown in the log is :- java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:144) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:21 37) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java, Compiled Code) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code) at java.lang.Thread.run(Thread.java:479) This worked fine under Struts 1.0b1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-328) File Upload mangles files
[ http://issues.apache.org/struts/browse/STR-328?page=all ] Don Brown reopened STR-328: --- Assign To: (was: Mike Schachter) File Upload mangles files - Key: STR-328 URL: http://issues.apache.org/struts/browse/STR-328 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: other Platform: PC Reporter: tom tibbetts Priority: Critical Fix For: 1.0.2 Attachments: Acrobat.pdf, BufferedMultipartInputStream.java, MultipartIterator.java, MultipartIterator.java, Whatsnew.PDF File Upload seems to do something to my PDF files which renders them unreadable to Acrobat reader. It seems it doesn't change the file size tho. please contact me if you need a sample pdf file at [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-328) File Upload mangles files
[ http://issues.apache.org/struts/browse/STR-328?page=all ] Don Brown closed STR-328: - Resolution: Fixed File Upload mangles files - Key: STR-328 URL: http://issues.apache.org/struts/browse/STR-328 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: other Platform: PC Reporter: tom tibbetts Priority: Critical Fix For: 1.0.2 Attachments: Acrobat.pdf, BufferedMultipartInputStream.java, MultipartIterator.java, MultipartIterator.java, Whatsnew.PDF File Upload seems to do something to my PDF files which renders them unreadable to Acrobat reader. It seems it doesn't change the file size tho. please contact me if you need a sample pdf file at [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-979) RedirectingActionForward to external URL's stopped working
[ http://issues.apache.org/struts/browse/STR-979?page=all ] Don Brown reopened STR-979: --- Assign To: (was: Struts Developer Mailing List) RedirectingActionForward to external URL's stopped working -- Key: STR-979 URL: http://issues.apache.org/struts/browse/STR-979 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Jo Are Rosland Priority: Critical An ActionForward or ForwardConfig with redirect set to true always gets the web project context path prepended to the uri prior to the call to HttpServletResponse.sendRedirect(). As a result of this, redirecting only works to an URI inside the web project. This is not how it worked in Struts 1.0. This seems to have been introduced in the 1.13 version of RequestProcessor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1757) FormFile.getFileName() problem in multibyte character file name
[ http://issues.apache.org/struts/browse/STR-1757?page=all ] David Evans reopened STR-1757: -- Assign To: David Evans (was: Struts Developer Mailing List) FormFile.getFileName() problem in multibyte character file name --- Key: STR-1757 URL: http://issues.apache.org/struts/browse/STR-1757 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: miyamiya Assignee: David Evans Fix For: 1.2 Family Attachments: CommonsMultipartRequestHandler.java.diff CommonsMultipartRequestHandler#handleRequest(HttpServletRequest) used DiskFileUpload but not called DiskFileUpload#setHeaderEncoding(String) so I can't get file name correctry when the browzer(html) character encoding is different from servlet container. I think like following statement in handleRequest method. -- String encoding = request.getCharacterEncoding(); upload.setHeaderEncoding(encoding); -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1757) FormFile.getFileName() problem in multibyte character file name
[ http://issues.apache.org/struts/browse/STR-1757?page=all ] David Evans closed STR-1757: Resolution: Fixed FormFile.getFileName() problem in multibyte character file name --- Key: STR-1757 URL: http://issues.apache.org/struts/browse/STR-1757 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: miyamiya Assignee: David Evans Fix For: 1.2 Family Attachments: CommonsMultipartRequestHandler.java.diff CommonsMultipartRequestHandler#handleRequest(HttpServletRequest) used DiskFileUpload but not called DiskFileUpload#setHeaderEncoding(String) so I can't get file name correctry when the browzer(html) character encoding is different from servlet container. I think like following statement in handleRequest method. -- String encoding = request.getCharacterEncoding(); upload.setHeaderEncoding(encoding); -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-979) RedirectingActionForward to external URL's stopped working
[ http://issues.apache.org/struts/browse/STR-979?page=all ] Don Brown closed STR-979: - Resolution: Fixed RedirectingActionForward to external URL's stopped working -- Key: STR-979 URL: http://issues.apache.org/struts/browse/STR-979 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Jo Are Rosland Priority: Critical An ActionForward or ForwardConfig with redirect set to true always gets the web project context path prepended to the uri prior to the call to HttpServletResponse.sendRedirect(). As a result of this, redirecting only works to an URI inside the web project. This is not how it worked in Struts 1.0. This seems to have been introduced in the 1.13 version of RequestProcessor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-753) Application not loading because of ClassLoad error in ActionServlet
[ http://issues.apache.org/struts/browse/STR-753?page=all ] Don Brown closed STR-753: - Resolution: Fixed Application not loading because of ClassLoad error in ActionServlet --- Key: STR-753 URL: http://issues.apache.org/struts/browse/STR-753 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: All Platform: PC Reporter: Dinesh Sadhvani Priority: Critical Environment : Weblogic 6.0 Server We are using ActionServlet and ActionComponentServlet (of Tiles) in our Application. The web.xml contains the servletaction which maps to ActionComponentServlet. ActionComponentServlet subclasses the ActionServlet ...I get the following stack trace :- org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundExc eption: org.apache.commons.logging.impl.LogFactoryImpl at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:497) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:350) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:381) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:331) at org.apache.struts.tiles.ActionComponentServlet.init(ActionComponent Servlet.java:41) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm pl.java:665) at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub Impl.java:643) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI mpl.java:588) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS ervletContext.java:2221) at weblogic.servlet.internal.WebAppServletContext.preloadServlets(WebApp ServletContext.java:2165) at weblogic.servlet.internal.HttpServer.preloadServlets(HttpServer.java: 475) at weblogic.servlet.internal.WebService.preloadServlets(WebService.java: 450) at weblogic.t3.srvr.ServletInitRunner.run(ServletInitRunner.java:49) at java.lang.Thread.run(Thread.java:484) The commons-logging.jar is present in the WEB-INF\lib directory, and the LogFactoryImpl is present in the jar file. Surprisingly when I hot-deploy the application into the container, it works fine. It seems to me that this has to do with the order in which classes get loaded. (Since there is no spec for hot-deploy class loading). I have seen other Web-sites where the same problem is being reported by others. I would appreciate if someone can fix this problem ASAP. The Suggested Fix for this problem is in the ActionServlet : Line 331 needs to be initialized to null (i.e. we do a lazy initialize in the init() method before doing the initInternal etc. I would appreciate if someone can fix this problem as apparently a lot of people have the same issue. Please feel free to email me for any questions. Thanks Dinesh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-753) Application not loading because of ClassLoad error in ActionServlet
[ http://issues.apache.org/struts/browse/STR-753?page=all ] Don Brown reopened STR-753: --- Assign To: (was: Struts Developer Mailing List) Application not loading because of ClassLoad error in ActionServlet --- Key: STR-753 URL: http://issues.apache.org/struts/browse/STR-753 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: All Platform: PC Reporter: Dinesh Sadhvani Priority: Critical Environment : Weblogic 6.0 Server We are using ActionServlet and ActionComponentServlet (of Tiles) in our Application. The web.xml contains the servletaction which maps to ActionComponentServlet. ActionComponentServlet subclasses the ActionServlet ...I get the following stack trace :- org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundExc eption: org.apache.commons.logging.impl.LogFactoryImpl at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:497) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:350) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:381) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:331) at org.apache.struts.tiles.ActionComponentServlet.init(ActionComponent Servlet.java:41) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm pl.java:665) at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub Impl.java:643) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI mpl.java:588) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS ervletContext.java:2221) at weblogic.servlet.internal.WebAppServletContext.preloadServlets(WebApp ServletContext.java:2165) at weblogic.servlet.internal.HttpServer.preloadServlets(HttpServer.java: 475) at weblogic.servlet.internal.WebService.preloadServlets(WebService.java: 450) at weblogic.t3.srvr.ServletInitRunner.run(ServletInitRunner.java:49) at java.lang.Thread.run(Thread.java:484) The commons-logging.jar is present in the WEB-INF\lib directory, and the LogFactoryImpl is present in the jar file. Surprisingly when I hot-deploy the application into the container, it works fine. It seems to me that this has to do with the order in which classes get loaded. (Since there is no spec for hot-deploy class loading). I have seen other Web-sites where the same problem is being reported by others. I would appreciate if someone can fix this problem ASAP. The Suggested Fix for this problem is in the ActionServlet : Line 331 needs to be initialized to null (i.e. we do a lazy initialize in the init() method before doing the initInternal etc. I would appreciate if someone can fix this problem as apparently a lot of people have the same issue. Please feel free to email me for any questions. Thanks Dinesh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1695) Each tag class loads a separate copy of its package's MessageResources
[ http://issues.apache.org/struts/browse/STR-1695?page=all ] David Evans reopened STR-1695: -- Assign To: David Evans (was: Struts Developer Mailing List) Each tag class loads a separate copy of its package's MessageResources -- Key: STR-1695 URL: http://issues.apache.org/struts/browse/STR-1695 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: 1.1 Final Environment: Operating System: other Platform: Other Reporter: Matt Meyer Assignee: David Evans Priority: Minor Attachments: PropertyMessageResourcesFactory.patch For example the MessageResources under the key org.apache.struts.taglib.html.LocalStrings has a potential to be read from the file system and stored in memory 18 separate times. Although not a serious performance bottle neck it could easily be corrected by having the PropertyMessageResourcesFactory cache MessageResource objects that it has created, and then consult it's cache before running off and creating new instances. Also ideally all of the classes that maintain local copies/references could be reconfigured to consult the factory instead of looking locally. If the factory was caching the loss in performance would be unnoticeable. Then If needed the cache could be dumped forcing MessageReasources to reloaded without an application restart. The list of classes that keep local copies of MessageResources is below: org.apache.struts.action.ActionServlet org.apache.struts.taglib.html.MessagesTag org.apache.struts.actions.DispatchAction org.apache.struts.actions.ForwardAction org.apache.struts.actions.IncludeAction org.apache.struts.actions.SwitchAction org.apache.struts.taglib.bean.CookieTag org.apache.struts.taglib.bean.DefineTag org.apache.struts.taglib.bean.HeaderTag org.apache.struts.taglib.bean.IncludeTag org.apache.struts.taglib.bean.MessageTag org.apache.struts.taglib.bean.PageTag org.apache.struts.taglib.bean.ParameterTag org.apache.struts.taglib.bean.ResourceTag org.apache.struts.taglib.bean.SizeTag org.apache.struts.taglib.bean.StrutsTag org.apache.struts.taglib.bean.WriteTag org.apache.struts.taglib.html.BaseHandlerTag org.apache.struts.taglib.html.BaseInputTag org.apache.struts.taglib.html.BaseTag org.apache.struts.taglib.html.CancelTag org.apache.struts.taglib.html.CheckboxTag org.apache.struts.taglib.html.ErrorsTag org.apache.struts.taglib.html.FormTag org.apache.struts.taglib.html.HtmlTag org.apache.struts.taglib.html.ImgTag org.apache.struts.taglib.html.LinkTag org.apache.struts.taglib.html.MultiboxTag org.apache.struts.taglib.html.OptionsCollectionTag org.apache.struts.taglib.html.OptionsTag org.apache.struts.taglib.html.OptionTag org.apache.struts.taglib.html.RadioTag org.apache.struts.taglib.html.ResetTag org.apache.struts.taglib.html.SelectTag org.apache.struts.taglib.html.SubmitTag org.apache.struts.taglib.logic.CompareTagBase org.apache.struts.taglib.logic.ConditionalTagBase org.apache.struts.taglib.logic.ForwardTag org.apache.struts.taglib.logic.IterateTag org.apache.struts.taglib.logic.RedirectTag org.apache.struts.util.RequestUtils org.apache.struts.util.ResponseUtils -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1695) Each tag class loads a separate copy of its package's MessageResources
[ http://issues.apache.org/struts/browse/STR-1695?page=all ] David Evans closed STR-1695: Resolution: Fixed Each tag class loads a separate copy of its package's MessageResources -- Key: STR-1695 URL: http://issues.apache.org/struts/browse/STR-1695 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: 1.1 Final Environment: Operating System: other Platform: Other Reporter: Matt Meyer Assignee: David Evans Priority: Minor Attachments: PropertyMessageResourcesFactory.patch For example the MessageResources under the key org.apache.struts.taglib.html.LocalStrings has a potential to be read from the file system and stored in memory 18 separate times. Although not a serious performance bottle neck it could easily be corrected by having the PropertyMessageResourcesFactory cache MessageResource objects that it has created, and then consult it's cache before running off and creating new instances. Also ideally all of the classes that maintain local copies/references could be reconfigured to consult the factory instead of looking locally. If the factory was caching the loss in performance would be unnoticeable. Then If needed the cache could be dumped forcing MessageReasources to reloaded without an application restart. The list of classes that keep local copies of MessageResources is below: org.apache.struts.action.ActionServlet org.apache.struts.taglib.html.MessagesTag org.apache.struts.actions.DispatchAction org.apache.struts.actions.ForwardAction org.apache.struts.actions.IncludeAction org.apache.struts.actions.SwitchAction org.apache.struts.taglib.bean.CookieTag org.apache.struts.taglib.bean.DefineTag org.apache.struts.taglib.bean.HeaderTag org.apache.struts.taglib.bean.IncludeTag org.apache.struts.taglib.bean.MessageTag org.apache.struts.taglib.bean.PageTag org.apache.struts.taglib.bean.ParameterTag org.apache.struts.taglib.bean.ResourceTag org.apache.struts.taglib.bean.SizeTag org.apache.struts.taglib.bean.StrutsTag org.apache.struts.taglib.bean.WriteTag org.apache.struts.taglib.html.BaseHandlerTag org.apache.struts.taglib.html.BaseInputTag org.apache.struts.taglib.html.BaseTag org.apache.struts.taglib.html.CancelTag org.apache.struts.taglib.html.CheckboxTag org.apache.struts.taglib.html.ErrorsTag org.apache.struts.taglib.html.FormTag org.apache.struts.taglib.html.HtmlTag org.apache.struts.taglib.html.ImgTag org.apache.struts.taglib.html.LinkTag org.apache.struts.taglib.html.MultiboxTag org.apache.struts.taglib.html.OptionsCollectionTag org.apache.struts.taglib.html.OptionsTag org.apache.struts.taglib.html.OptionTag org.apache.struts.taglib.html.RadioTag org.apache.struts.taglib.html.ResetTag org.apache.struts.taglib.html.SelectTag org.apache.struts.taglib.html.SubmitTag org.apache.struts.taglib.logic.CompareTagBase org.apache.struts.taglib.logic.ConditionalTagBase org.apache.struts.taglib.logic.ForwardTag org.apache.struts.taglib.logic.IterateTag org.apache.struts.taglib.logic.RedirectTag org.apache.struts.util.RequestUtils org.apache.struts.util.ResponseUtils -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (STR-2843) CLONE -PropertyMessageResources.loadLocale(String localeKey) has a problem!
CLONE -PropertyMessageResources.loadLocale(String localeKey) has a problem!
---
Key: STR-2843
URL: http://issues.apache.org/struts/browse/STR-2843
Project: Struts Action 1
Type: Bug
Components: Action
Versions: Nightly Build
Environment: Operating System: other
Platform: Other
Reporter: qxo
Assigned to: Struts Developer Mailing List
when
struts-config.xml --message-resources --parameter:resourceA
if resourceA not existed,it should show some error message,but not!
cause:
PropertyMessageResources.loadLocale(String localeKey) has a problem!
I fixed it;
Code:
protected synchronized void loadLocale(String localeKey) {
// Have we already attempted to load messages for this locale?
if (locales.get(localeKey) != null) {
return;
}
if (log.isTraceEnabled()) {
log.trace(loadLocale( + localeKey + ));
}
locales.put(localeKey, localeKey);
// Set up to load the property resource for this locale key, if we
can
String name = config.replace('.', '/');
if (localeKey.length() 0) {
name += _ + localeKey;
}
name += .properties;
InputStream is = null;
// Load the specified property resource
if (log.isTraceEnabled()) {
log.trace( Loading resource ' + name + ');
}
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
classLoader = this.getClass().getClassLoader();
}
is = classLoader.getResourceAsStream(name);
if (is != null) {
Properties props = new Properties();
try {
props.load(is);
} catch (IOException e) {
log.error(loadLocale(), e);
} finally {
try {
is.close();
} catch (IOException e) {
log.error(loadLocale(), e);
}
}
// Copy the corresponding values into our cache
if (props.size() 1) {
return;
}
synchronized (messages) {
Iterator names = props.keySet().iterator();
while (names.hasNext()) {
String key = (String) names.next();
if (log.isTraceEnabled()) {
log.trace( Saving message key ' +
messageKey(localeKey, key));
}
messages.put(messageKey(localeKey, key),
props.getProperty(key));
}
}
if (log.isTraceEnabled()) {
log.trace( Loading resource completed);
}
}else{
if (log.isWarnEnabled()) {
log.warn(the resource not found.);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Deleted: (STR-2485) PropertyMessageResources.loadLocale(String localeKey) has a problem!
[ http://issues.apache.org/struts/browse/STR-2485?page=all ]
Don Brown deleted STR-2485:
---
PropertyMessageResources.loadLocale(String localeKey) has a problem!
Key: STR-2485
URL: http://issues.apache.org/struts/browse/STR-2485
Project: Struts Action 1
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: qxo
Assignee: Struts Developer Mailing List
when
struts-config.xml --message-resources --parameter:resourceA
if resourceA not existed,it should show some error message,but not!
cause:
PropertyMessageResources.loadLocale(String localeKey) has a problem!
I fixed it;
Code:
protected synchronized void loadLocale(String localeKey) {
// Have we already attempted to load messages for this locale?
if (locales.get(localeKey) != null) {
return;
}
if (log.isTraceEnabled()) {
log.trace(loadLocale( + localeKey + ));
}
locales.put(localeKey, localeKey);
// Set up to load the property resource for this locale key, if
we can
String name = config.replace('.', '/');
if (localeKey.length() 0) {
name += _ + localeKey;
}
name += .properties;
InputStream is = null;
// Load the specified property resource
if (log.isTraceEnabled()) {
log.trace( Loading resource ' + name + ');
}
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
classLoader = this.getClass().getClassLoader();
}
is = classLoader.getResourceAsStream(name);
if (is != null) {
Properties props = new Properties();
try {
props.load(is);
} catch (IOException e) {
log.error(loadLocale(), e);
} finally {
try {
is.close();
} catch (IOException e) {
log.error(loadLocale(), e);
}
}
// Copy the corresponding values into our cache
if (props.size() 1) {
return;
}
synchronized (messages) {
Iterator names = props.keySet().iterator();
while (names.hasNext()) {
String key = (String) names.next();
if (log.isTraceEnabled()) {
log.trace( Saving message key ' +
messageKey(localeKey, key));
}
messages.put(messageKey(localeKey, key),
props.getProperty(key));
}
}
if (log.isTraceEnabled()) {
log.trace( Loading resource completed);
}
}else{
if (log.isWarnEnabled()) {
log.warn(the resource not found.);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On Tue, April 25, 2006 2:22 pm, Paul Speed said: Frank W. Zammetti wrote: You are of course right about this. But, much like taking the ideas about inventory control and order processing and such from Dell and starting your own business is possible, the likelihood that you would get anything but a small fraction of the attention and business that Dell gets is slim to none. Not to sidle in where I don't really belong but perhaps this last sentence exemplifies the disconnect with getting it? If one wanted to take the code from an apache project and do something else with it then all they care about is the something else they want to do. It isn't really a business... the code exists for the code's sake. You aren't chiming in where you don't belong... if your interested, you belong, at least as far as I'm concerned :) I think there is definitely something to your point, and the analogy may have been a bit flawed. However... I don't think it is accurate to think that ego doesn't play a part in just about everything that just about everyone does. We all want to see our work benefit others. For most of us I believe its because we genuinely like the feeling we get when someone writes us and says hey, your code really helped me, thank you!. I know speaking for myself, it makes my day when I get those eMails! Part of it is simply the ego stroke of someone essentially saying your work is worth something, but I don't believe that is the big factor for most people. I know it isn't for me, and I don't think it is for the Struts team. I think the thank you note means as much to them as it does me. If you agree with that, then the idea of forking the code and doing it with the belief that you aren't going to reach a wide audience because the Apache version continues to be what people go to, is not appealing. In that regard, if we substitute ego for money in the analogy, I think it still works (although just saying ego is dangerous because as I tried to illustrate above, I think there is good ego and bad ego). I'm not a committer but I've been following this list and the tomcat dev list since the last millennium... I think before there even was a struts 1.0. I can't speak in an official capacity, I can't even pretend, but here is my take on the apache way. Isn't kind of interesting that there can be more than one take on it though? For an open source project to exist you need code. All of apache projects seem to exist to benefit the code... and by extension the documentation. Though, even without documentation you still have the code. All of the other stuff is extraneous or the life support system depending on how you look at it. I think most of the apache way is partially considering it to be extraneous... in a if the code goes sour and you have nothing sort of way. It's definitely symbiotic but without the code, you have nothing. You might as well be chatting on myspace.com. Hehe, considering some of the recent threads around here, posting on myspace.com might actually be safer! :-) LOL So, the only reason to be a committer is to contribute to the codebase... and all other committers have to live with each other. The only reason to be able to cast a binding vote is if you have a stake in the code... ie: are a committer. This is where I'm not sure I agree... why can you only have a stake in the code, or in the community even, if you are a committer? And certainly the community is often touted as the most important part of any ASF project... it's just that community in that context means the committers only, which is where I disagree with the Apache Way I guess. Simply putting code out there and sharing your work is great, but going back to a point I made some weeks ago, I beleive there is a responsibility that comes along with it when you do that. Whether they should or not, people become dependent on the project... not in a cocaine kind of way of course, but they are counting on you basically. That to me implies taking into consideration their needs and wants. Not above your own of course, but to some degree. Bottom line: if a person isn't contributing to code and documentation in a way that the other committers are comfortable with then that person shouldn't be a committer on the project. There is no other reason for being a committer. This I absolutely agree with, and it was the reason my proposal didn't try to change that. I would NEVER propose that the PMC not have the final say in who is invited. It just to me seems right for that to be the case. But, I still see nothing wrong with being able to say hey, PMC, we think this guy or gal would be a good addition, please consider him. My personal (and probably unneeded) opinion on the original subject: From my perspective, nominations don't matter so much... as I recall someone could nominate themselves. If that person hasn't been contributing code then there is no reason to think
[jira] Reopened: (STR-196) MultipartRequestHandler does not handle html:select multiple
[ http://issues.apache.org/struts/browse/STR-196?page=all ] Don Brown reopened STR-196: --- Assign To: (was: Mike Schachter) MultipartRequestHandler does not handle html:select multiple Key: STR-196 URL: http://issues.apache.org/struts/browse/STR-196 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 1 Environment: Operating System: other Platform: PC Reporter: Bienvenido David III Fix For: 1.0.0 The MultipartRequestHandler interface does not handle multiple selected options. Since MultipartRequestHandler.getAllElements() returns a Hashtable, the other values are overwritten and only the last option is kept. You will see this happening in DiskMultipartRequestHandler.handleRequest(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (STR-2843) PropertyMessageResources.loadLocale(String localeKey) has a problem!
[ http://issues.apache.org/struts/browse/STR-2843?page=all ]
Don Brown updated STR-2843:
---
Summary: PropertyMessageResources.loadLocale(String localeKey) has a
problem! (was: CLONE -PropertyMessageResources.loadLocale(String localeKey)
has a problem!)
Bugzilla Id: (was: 35155)
Assign To: (was: Struts Developer Mailing List)
Had to clone due to corrupted ticket
PropertyMessageResources.loadLocale(String localeKey) has a problem!
Key: STR-2843
URL: http://issues.apache.org/struts/browse/STR-2843
Project: Struts Action 1
Type: Bug
Components: Action
Versions: Nightly Build
Environment: Operating System: other
Platform: Other
Reporter: qxo
when
struts-config.xml --message-resources --parameter:resourceA
if resourceA not existed,it should show some error message,but not!
cause:
PropertyMessageResources.loadLocale(String localeKey) has a problem!
I fixed it;
Code:
protected synchronized void loadLocale(String localeKey) {
// Have we already attempted to load messages for this locale?
if (locales.get(localeKey) != null) {
return;
}
if (log.isTraceEnabled()) {
log.trace(loadLocale( + localeKey + ));
}
locales.put(localeKey, localeKey);
// Set up to load the property resource for this locale key, if
we can
String name = config.replace('.', '/');
if (localeKey.length() 0) {
name += _ + localeKey;
}
name += .properties;
InputStream is = null;
// Load the specified property resource
if (log.isTraceEnabled()) {
log.trace( Loading resource ' + name + ');
}
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
classLoader = this.getClass().getClassLoader();
}
is = classLoader.getResourceAsStream(name);
if (is != null) {
Properties props = new Properties();
try {
props.load(is);
} catch (IOException e) {
log.error(loadLocale(), e);
} finally {
try {
is.close();
} catch (IOException e) {
log.error(loadLocale(), e);
}
}
// Copy the corresponding values into our cache
if (props.size() 1) {
return;
}
synchronized (messages) {
Iterator names = props.keySet().iterator();
while (names.hasNext()) {
String key = (String) names.next();
if (log.isTraceEnabled()) {
log.trace( Saving message key ' +
messageKey(localeKey, key));
}
messages.put(messageKey(localeKey, key),
props.getProperty(key));
}
}
if (log.isTraceEnabled()) {
log.trace( Loading resource completed);
}
}else{
if (log.isWarnEnabled()) {
log.warn(the resource not found.);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-196) MultipartRequestHandler does not handle html:select multiple
[ http://issues.apache.org/struts/browse/STR-196?page=all ] Don Brown closed STR-196: - Resolution: Fixed MultipartRequestHandler does not handle html:select multiple Key: STR-196 URL: http://issues.apache.org/struts/browse/STR-196 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 1 Environment: Operating System: other Platform: PC Reporter: Bienvenido David III Fix For: 1.0.0 The MultipartRequestHandler interface does not handle multiple selected options. Since MultipartRequestHandler.getAllElements() returns a Hashtable, the other values are overwritten and only the last option is kept. You will see this happening in DiskMultipartRequestHandler.handleRequest(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-200) Connection Pool does not handle stale (closed) connections
[ http://issues.apache.org/struts/browse/STR-200?page=all ]
Don Brown reopened STR-200:
---
Connection Pool does not handle stale (closed) connections
--
Key: STR-200
URL: http://issues.apache.org/struts/browse/STR-200
Project: Struts Action 1
Type: Bug
Components: Action
Versions: 1.0 Beta 2
Environment: Operating System: other
Platform: Sun
Reporter: hnguyen
Assignee: Craig McClanahan
Fix For: 1.0.0
Struts connection pool implemented in GenericDataSource.java does not handle
stale connections.
Stale connections are connections having been closed by the database. This
could be due to no activity timeout (such as wait_timeout in mysql) or the
database was down and up again. Currently when returning a pool connection
to
a caller in getConnection(), Struts does not check if the real database
connection of that pool connection has been closed or not.
Below is my patch for this problem in the GenericDataSource.java, revision 1.5
*** GenericDataSource.java.r1.5 Wed May 23 17:44:12 2001
--- GenericDataSource.java.r1.5fixed Wed May 23 17:31:07 2001
***
*** 402,414
// Return an existing connection from the pool if there is one
synchronized (connections) {
! if (!connections.isEmpty()) {
! useCount++;
GenericConnection connection = (GenericConnection)
connections.removeFirst();
// unclose the connection's wrapper
connection.setClosed(false);
return(connection);
! // return ((Connection) connections.removeFirst());
DEBUG
}
}
--- 402,425
// Return an existing connection from the pool if there is one
synchronized (connections) {
! while (!connections.isEmpty()) {
GenericConnection connection = (GenericConnection)
connections.removeFirst();
+ // Checking for stale connection. Stale connections
are
connections
+ // closed by the database. This could be due to no
activity
+ // timeout (such as mysql wait_timeout) or the database
was down
+ // and up again.
+ if (connection.getConnection().isClosed())
+ {
+ activeCount --;
+ connection = null;
+ continue;
+ }
+ else {
// unclose the connection's wrapper
+ useCount++;
connection.setClosed(false);
return(connection);
! }
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-200) Connection Pool does not handle stale (closed) connections
[ http://issues.apache.org/struts/browse/STR-200?page=all ]
Don Brown closed STR-200:
-
Resolution: Fixed
Connection Pool does not handle stale (closed) connections
--
Key: STR-200
URL: http://issues.apache.org/struts/browse/STR-200
Project: Struts Action 1
Type: Bug
Components: Action
Versions: 1.0 Beta 2
Environment: Operating System: other
Platform: Sun
Reporter: hnguyen
Assignee: Craig McClanahan
Fix For: 1.0.0
Struts connection pool implemented in GenericDataSource.java does not handle
stale connections.
Stale connections are connections having been closed by the database. This
could be due to no activity timeout (such as wait_timeout in mysql) or the
database was down and up again. Currently when returning a pool connection
to
a caller in getConnection(), Struts does not check if the real database
connection of that pool connection has been closed or not.
Below is my patch for this problem in the GenericDataSource.java, revision 1.5
*** GenericDataSource.java.r1.5 Wed May 23 17:44:12 2001
--- GenericDataSource.java.r1.5fixed Wed May 23 17:31:07 2001
***
*** 402,414
// Return an existing connection from the pool if there is one
synchronized (connections) {
! if (!connections.isEmpty()) {
! useCount++;
GenericConnection connection = (GenericConnection)
connections.removeFirst();
// unclose the connection's wrapper
connection.setClosed(false);
return(connection);
! // return ((Connection) connections.removeFirst());
DEBUG
}
}
--- 402,425
// Return an existing connection from the pool if there is one
synchronized (connections) {
! while (!connections.isEmpty()) {
GenericConnection connection = (GenericConnection)
connections.removeFirst();
+ // Checking for stale connection. Stale connections
are
connections
+ // closed by the database. This could be due to no
activity
+ // timeout (such as mysql wait_timeout) or the database
was down
+ // and up again.
+ if (connection.getConnection().isClosed())
+ {
+ activeCount --;
+ connection = null;
+ continue;
+ }
+ else {
// unclose the connection's wrapper
+ useCount++;
connection.setClosed(false);
return(connection);
! }
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-217) form-validation does not work with multipart-requests
[ http://issues.apache.org/struts/browse/STR-217?page=all ] Don Brown reopened STR-217: --- Assign To: (was: Mike Schachter) form-validation does not work with multipart-requests - Key: STR-217 URL: http://issues.apache.org/struts/browse/STR-217 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 3 Environment: Operating System: All Platform: PC Reporter: outermedia developer Fix For: 1.0.0 I validate a form with enctype=multipart/form-data. When validation fails (finds errors) I get an Exception in MultipartRequestWrapper instead of seeing the page again in order to correct errors. Stacktrace is: java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl.jav a:144) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:2126) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1553) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:508) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConne ctionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-285) Erroneous shortcircuit in org.apache.struts.util.RequestUtils.computeParameters
[ http://issues.apache.org/struts/browse/STR-285?page=all ] Don Brown reopened STR-285: --- Erroneous shortcircuit in org.apache.struts.util.RequestUtils.computeParameters --- Key: STR-285 URL: http://issues.apache.org/struts/browse/STR-285 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Oliver Willenbrock Assignee: Craig McClanahan Fix For: 1.0.2 The shortcircuit at the begin of the method org.apache.struts.util.RequestUtils.computeParameters is erroneous. if u just want to have a link with a transaction token but no parameters it won't work: html:link href=foo transaction=truebar/html:link doesn't generate a link with a transaction token. Changing the if-statement to if ((paramId == null) (name == null) !transaction) return (null); fixes the problem (i added just the !transaction in the statement). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-217) form-validation does not work with multipart-requests
[ http://issues.apache.org/struts/browse/STR-217?page=all ] Don Brown closed STR-217: - Resolution: Fixed form-validation does not work with multipart-requests - Key: STR-217 URL: http://issues.apache.org/struts/browse/STR-217 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Beta 3 Environment: Operating System: All Platform: PC Reporter: outermedia developer Fix For: 1.0.0 I validate a form with enctype=multipart/form-data. When validation fails (finds errors) I get an Exception in MultipartRequestWrapper instead of seeing the page again in order to correct errors. Stacktrace is: java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl.jav a:144) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:2126) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1553) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:508) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConne ctionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-289) File Upload doesn't work with Opera
[ http://issues.apache.org/struts/browse/STR-289?page=all ] Don Brown reopened STR-289: --- Assign To: (was: Mike Schachter) File Upload doesn't work with Opera --- Key: STR-289 URL: http://issues.apache.org/struts/browse/STR-289 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: Linux Platform: Other Reporter: Calvin Yu Attachments: HttpRequestAdapter.diff, MultipartIterator.diff Opera version: 5.12 Performing a file upload causes the following exception: java.lang.NullPointerException at org.apache.struts.upload.MultipartIterator.parseRequest(MultipartIterator.java:307) at org.apache.struts.upload.MultipartIterator.(MultipartIterator.java:152) at org.apache.struts.upload.DiskMultipartRequestHandler.handleRequest(DiskMultipartRequestHandler.java:65) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:735) at org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:2061) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1563) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at com.iqresq.web.ActionServlet.service(ActionServlet.java:37) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) I don't think this is specific to Linux - I'd seen this happen in opera for windows as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-285) Erroneous shortcircuit in org.apache.struts.util.RequestUtils.computeParameters
[ http://issues.apache.org/struts/browse/STR-285?page=all ] Don Brown closed STR-285: - Resolution: Fixed Erroneous shortcircuit in org.apache.struts.util.RequestUtils.computeParameters --- Key: STR-285 URL: http://issues.apache.org/struts/browse/STR-285 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Oliver Willenbrock Assignee: Craig McClanahan Fix For: 1.0.2 The shortcircuit at the begin of the method org.apache.struts.util.RequestUtils.computeParameters is erroneous. if u just want to have a link with a transaction token but no parameters it won't work: html:link href=foo transaction=truebar/html:link doesn't generate a link with a transaction token. Changing the if-statement to if ((paramId == null) (name == null) !transaction) return (null); fixes the problem (i added just the !transaction in the statement). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1687) Sorting enhancements for LabelValueBean
[ http://issues.apache.org/struts/browse/STR-1687?page=all ]
David Evans reopened STR-1687:
--
Assign To: David Evans (was: Struts Developer Mailing List)
Sorting enhancements for LabelValueBean
---
Key: STR-1687
URL: http://issues.apache.org/struts/browse/STR-1687
Project: Struts Action 1
Type: Improvement
Components: Action
Versions: Unknown
Environment: Operating System: All
Platform: All
Reporter: Paul Sundling
Assignee: David Evans
Priority: Minor
Fix For: 1.2 Family
Attachments: sortableBean.txt
Hopefully you will see fit to accept my code and allow me to make my first
non-documentation open source contribution. The code I have added makes it
VERY
easy to sort an array of LabelValueBeans for display in select lists.
Here's a sample of how to use the newly added functionality
inside the execute function of an Action used for setup
LabelValueBean[] sortableList = new LabelValueBean[] {
new LabelValueBean(unorganized, ung),
new LabelValueBean(out of order, ood),
new LabelValueBean(Capitalized, Cap),
new LabelValueBean(Not Lowercase, Nl),
};
// to sort the list alphabetically by label
java.util.Arrays.sort(sortableList);
// or to sort the list case insensitive by label
java.util.Arrays.sort(sortableList, LabelValueBean.CASE_INSENSITIVE_ORDER);
request.setAttribute(sortableList, sortableList);
//then the sortableList is used in the html:options tags..
Following is the output of the cvs diff:
# cvs diff -u
cvs server: Diffing .
Index: LabelValueBean.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java,v
retrieving revision 1.6
diff -u -r1.6 LabelValueBean.java
--- LabelValueBean.java 4 Jul 2003 18:26:19 - 1.6
+++ LabelValueBean.java 15 Aug 2003 17:09:53 -
@@ -62,7 +62,7 @@
package org.apache.struts.util;
import java.io.Serializable;
-
+import java.util.Comparator;
/**
* A simple JavaBean to represent label-value pairs. This is most commonly
used
* when constructing user interface elements which have a label to be
displayed@@ -72,9 +72,11 @@
* @author Craig R. McClanahan
* @author Martin F N Cooper
* @author David Graham
+ * @author Paul Sundling
+ *
* @version $Revision: 1.6 $ $Date: 2003/07/04 18:26:19 $
*/
-public class LabelValueBean implements Serializable {
+public class LabelValueBean implements Comparable, Serializable {
// ---
Constructors@@ -179,4 +181,31 @@
public int hashCode() {
return (this.getValue() == null) ? 17 : this.getValue().hashCode();
}
+/**
+ * The comparable interface allows sorting. This is done based on the
+ * label, since that is the human viewable part of the object.
+ * @see java.lang.Comparable
+ */
+public int compareTo(Object otherBean) {
+ // implicitly tests for the correct type, throwing ClassCastException
+ // as required by interface
+ String otherLabel = ((LabelValueBean)otherBean).getLabel();
+
+ //compare the labels of the LabelValueBean objects
+ return this.getLabel().compareTo(otherLabel);
+}
+
+/**
+ * Comparator object that can be used for a case insensitive order
+ * sort of LabelValueBean objects. The idea for this comes from
+ * java.lang.String
+ */
+ public static Comparator CASE_INSENSITIVE_ORDER = new Comparator() {
+ public int compare(Object Bean1, Object Bean2) {
+ String label1 = ((LabelValueBean)Bean1).getLabel();
+ String label2 = ((LabelValueBean)Bean2).getLabel();
+ return label1.compareToIgnoreCase(label2);
+
+ }
+ };
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On Tue, April 25, 2006 2:41 pm, Martin Cooper said: For me, the community would be anyone who has an active interest in how the project develops. There! You've said it. That exactly describes the purpose of the dev@ list. So, now, why again do we need the three lists you mention above? ;-) Ok, fair enough, I'll concede the point :) (Since suggesting three lists was *maybe* only 5% serious anyway, it's not such a big concession!) This whole discussion seems to have moved to the dev@ list anyway, which is fine by me, given the above. -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-289) File Upload doesn't work with Opera
[ http://issues.apache.org/struts/browse/STR-289?page=all ] Don Brown closed STR-289: - Resolution: Fixed File Upload doesn't work with Opera --- Key: STR-289 URL: http://issues.apache.org/struts/browse/STR-289 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: Linux Platform: Other Reporter: Calvin Yu Attachments: HttpRequestAdapter.diff, MultipartIterator.diff Opera version: 5.12 Performing a file upload causes the following exception: java.lang.NullPointerException at org.apache.struts.upload.MultipartIterator.parseRequest(MultipartIterator.java:307) at org.apache.struts.upload.MultipartIterator.(MultipartIterator.java:152) at org.apache.struts.upload.DiskMultipartRequestHandler.handleRequest(DiskMultipartRequestHandler.java:65) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:735) at org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:2061) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1563) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at com.iqresq.web.ActionServlet.service(ActionServlet.java:37) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) I don't think this is specific to Linux - I'd seen this happen in opera for windows as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-290) file upload problem: MultipartIterator: invalid multipart request data, doesn't start with boundary
[ http://issues.apache.org/struts/browse/STR-290?page=all ] Don Brown closed STR-290: - Resolution: Fixed file upload problem: MultipartIterator: invalid multipart request data, doesn't start with boundary --- Key: STR-290 URL: http://issues.apache.org/struts/browse/STR-290 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: All Platform: PC Reporter: Ken Brewer This error seems to be generated after returning an ActionForward instance from a request that was posted as a multipart(file upload). Returning a instead seems to be a workaround. javax.servlet.ServletException: MultipartIterator: invalid multipart request data, doesn't start with boundary at org.apache.struts.upload.MultipartIterator.parseRequest (MultipartIterator.java:345) at org.apache.struts.upload.MultipartIterator. (MultipartIterator.java:152) at org.apache.struts.upload.DiskMultipartRequestHandler.handleRequest (DiskMultipartRequestHandler.java:65) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:735) at org.apache.struts.action.ActionServlet.processPopulate (ActionServlet.java:2061) at org.apache.struts.action.ActionServlet.process (ActionServlet.java:1563) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:772) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1013) at allaire.jrun.servlet.JRunSE.runServlet(../servlet/JRunSE.java:925) at allaire.jrun.servlet.JRunRequestDispatcher.forward (../servlet/JRunRequestDispatcher.java:88) at org.apache.struts.action.ActionServlet.processActionForward (ActionServlet.java:1758) at org.apache.struts.action.ActionServlet.process (ActionServlet.java:1595) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509) at javax.servlet.http.HttpServlet.service(HttpServlet.java:772) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1013) at allaire.jrun.servlet.JRunSE.runServlet(../servlet/JRunSE.java:925) at allaire.jrun.servlet.JRunRequestDispatcher.forward (../servlet/JRunRequestDispatcher.java:88) at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1131) at allaire.jrun.servlet.JvmContext.dispatch (../servlet/JvmContext.java:330) at allaire.jrun.http.WebEndpoint.run(../http/WebEndpoint.java:107) at allaire.jrun.ThreadPool.run(../ThreadPool.java:272) at allaire.jrun.WorkerThread.run(../WorkerThread.java:75) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1687) Sorting enhancements for LabelValueBean
[ http://issues.apache.org/struts/browse/STR-1687?page=all ]
David Evans closed STR-1687:
Resolution: Fixed
Sorting enhancements for LabelValueBean
---
Key: STR-1687
URL: http://issues.apache.org/struts/browse/STR-1687
Project: Struts Action 1
Type: Improvement
Components: Action
Versions: Unknown
Environment: Operating System: All
Platform: All
Reporter: Paul Sundling
Assignee: David Evans
Priority: Minor
Fix For: 1.2 Family
Attachments: sortableBean.txt
Hopefully you will see fit to accept my code and allow me to make my first
non-documentation open source contribution. The code I have added makes it
VERY
easy to sort an array of LabelValueBeans for display in select lists.
Here's a sample of how to use the newly added functionality
inside the execute function of an Action used for setup
LabelValueBean[] sortableList = new LabelValueBean[] {
new LabelValueBean(unorganized, ung),
new LabelValueBean(out of order, ood),
new LabelValueBean(Capitalized, Cap),
new LabelValueBean(Not Lowercase, Nl),
};
// to sort the list alphabetically by label
java.util.Arrays.sort(sortableList);
// or to sort the list case insensitive by label
java.util.Arrays.sort(sortableList, LabelValueBean.CASE_INSENSITIVE_ORDER);
request.setAttribute(sortableList, sortableList);
//then the sortableList is used in the html:options tags..
Following is the output of the cvs diff:
# cvs diff -u
cvs server: Diffing .
Index: LabelValueBean.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java,v
retrieving revision 1.6
diff -u -r1.6 LabelValueBean.java
--- LabelValueBean.java 4 Jul 2003 18:26:19 - 1.6
+++ LabelValueBean.java 15 Aug 2003 17:09:53 -
@@ -62,7 +62,7 @@
package org.apache.struts.util;
import java.io.Serializable;
-
+import java.util.Comparator;
/**
* A simple JavaBean to represent label-value pairs. This is most commonly
used
* when constructing user interface elements which have a label to be
displayed@@ -72,9 +72,11 @@
* @author Craig R. McClanahan
* @author Martin F N Cooper
* @author David Graham
+ * @author Paul Sundling
+ *
* @version $Revision: 1.6 $ $Date: 2003/07/04 18:26:19 $
*/
-public class LabelValueBean implements Serializable {
+public class LabelValueBean implements Comparable, Serializable {
// ---
Constructors@@ -179,4 +181,31 @@
public int hashCode() {
return (this.getValue() == null) ? 17 : this.getValue().hashCode();
}
+/**
+ * The comparable interface allows sorting. This is done based on the
+ * label, since that is the human viewable part of the object.
+ * @see java.lang.Comparable
+ */
+public int compareTo(Object otherBean) {
+ // implicitly tests for the correct type, throwing ClassCastException
+ // as required by interface
+ String otherLabel = ((LabelValueBean)otherBean).getLabel();
+
+ //compare the labels of the LabelValueBean objects
+ return this.getLabel().compareTo(otherLabel);
+}
+
+/**
+ * Comparator object that can be used for a case insensitive order
+ * sort of LabelValueBean objects. The idea for this comes from
+ * java.lang.String
+ */
+ public static Comparator CASE_INSENSITIVE_ORDER = new Comparator() {
+ public int compare(Object Bean1, Object Bean2) {
+ String label1 = ((LabelValueBean)Bean1).getLabel();
+ String label2 = ((LabelValueBean)Bean2).getLabel();
+ return label1.compareToIgnoreCase(label2);
+
+ }
+ };
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1636) add accept-charset attribute to html:form
[ http://issues.apache.org/struts/browse/STR-1636?page=all ] David Evans reopened STR-1636: -- Assign To: David Evans (was: Struts Developer Mailing List) add accept-charset attribute to html:form - Key: STR-1636 URL: http://issues.apache.org/struts/browse/STR-1636 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: C. N. Assignee: David Evans Priority: Minor Fix For: 1.2 Family As defined in HTML http://www.w3.org/TR/html4/interact/forms.html The accept-charset attribute in HTML form tag specifies the list of character encodings for input data that is accepted by the server processing this form. Without this attribute user can change the encoding for themselves using menu options in browser (e.g. change to ISO-8859) but my JSP server expected the character encoding in UTF-8. With this attribute, I can force the encoding in UTF-8 as follows form action=... method=post accept-encoding=UTF-8 Thanks C.N. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-372) ResponseUtils.filter() does not encode the apostrophe character
[ http://issues.apache.org/struts/browse/STR-372?page=all ] Don Brown reopened STR-372: --- Assign To: (was: Struts Developer Mailing List) ResponseUtils.filter() does not encode the apostrophe character --- Key: STR-372 URL: http://issues.apache.org/struts/browse/STR-372 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Jon Ribbens Fix For: 1.1 Family Attachments: patch ResponseUtils.filter() encodes , , and but not '. It is necessary to encode ' in cases where the output is being used as an attribute value enclosed by ' characters. ( is more usual but ' is equally valid and is certainly used sometimes.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-1636) add accept-charset attribute to html:form
[ http://issues.apache.org/struts/browse/STR-1636?page=all ] David Evans closed STR-1636: Resolution: Fixed add accept-charset attribute to html:form - Key: STR-1636 URL: http://issues.apache.org/struts/browse/STR-1636 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: C. N. Assignee: David Evans Priority: Minor Fix For: 1.2 Family As defined in HTML http://www.w3.org/TR/html4/interact/forms.html The accept-charset attribute in HTML form tag specifies the list of character encodings for input data that is accepted by the server processing this form. Without this attribute user can change the encoding for themselves using menu options in browser (e.g. change to ISO-8859) but my JSP server expected the character encoding in UTF-8. With this attribute, I can force the encoding in UTF-8 as follows form action=... method=post accept-encoding=UTF-8 Thanks C.N. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-316) UTF-16 format character decode error when html-form use enctype as multipart/form-data
[ http://issues.apache.org/struts/browse/STR-316?page=all ]
Don Brown reopened STR-316:
---
Assign To: (was: Mike Schachter)
UTF-16 format character decode error when html-form use enctype as
multipart/form-data
Key: STR-316
URL: http://issues.apache.org/struts/browse/STR-316
Project: Struts Action 1
Type: Bug
Components: Action
Versions: 1.0 Final
Environment: Operating System: All
Platform: PC
Reporter: Lee Sure
I want to devolop a chinese version web application use struts.
Last week, I had tested struts html-tags in weblogic server 6.0sp2. When I
used
struts-html tags like this:
html:form action=/testChinese.do ENCTYPE=multipart/form-data
method=post
html:text name=testForm property=text /
html:file name=testForm property=uploadFile /
,
I had found the chinese characters I got from struts-action all like ??.
As antitheses, I only used a html-text field to test like this:
html:form action=/testChinese.do method=post
html:text name=testForm property=text /
,
the result is OK.
Test programs lists:
//testForm.java
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.upload.FormFile;
import java.util.Collection;
public class TestForm extends ActionForm {
private String text;
private FormFile uploadFile;
//
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
public FormFile getUploadFile () {
return this.uploadFile;
}
public void setUploadFile (FormFile uploadFile) {
this.uploadFile = uploadFile;
}
public void reset(ActionMapping mapping, HttpServletRequest request) {
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
return null;
}
}
// testAction.java
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.upload.FormFile;
public final class TestAction extends Action
{
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
//response.setContentType( text/html; charset=GB2312 ) ;
System.out.println(start of TestAction);
TestForm testForm = (TestForm)form;
try {
String text = testForm.getText();
System.out.println(#27721;#23383; is + text);
FormFile file = testForm.getUploadFile();
if (file.getFileSize() 1024000) {
throw new
IOException(#25991;#20214;#36229;#36807;#19968;#20806;#23383;#33410;,#19981;#33021;#22788;#29702;!);
}
InputStream is = file.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String testStr = br.readLine();
System.out.println(get upload file, the first line is +
testStr);
} catch (Exception ex) {
System.out.println(TestAction has Exception: + ex);
}
return (mapping.findForward(back));
}
}
// test.jsp
%@ page contentType=text/html; charset=gb2312 %
%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
%@ taglib uri=/WEB-INF/struts-html.tld prefix=html %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
html:html locale=true
head
title#27721;#23383;#27979;#35797;/title
html:base/
meta http-equiv=Content-Type content=text/html; charset=gb2312
/head
body bgcolor=#FF topmargin=0 rightmargin=2% leftmargin=2%
bottommargin=0
!-- content:begin --
table width=100% border=0 cellspacing=0 cellpadding=0
tr
td width=5%nbsp;/td
td width=95% height=11
html:form action=/testChinese.do ENCTYPE=multipart/form-
data method=post
table width=100% border=1 cellspacing=0
cellpadding=0 bordercolorlight=#FF bordercolordark=#FF
tr
td height=5 colspan=2nbsp;/td
/tr
tr height=25
[jira] Reopened: (STR-373) logic:messagesPresent tag
[ http://issues.apache.org/struts/browse/STR-373?page=all ] Don Brown reopened STR-373: --- Assign To: (was: Struts Developer Mailing List) logic:messagesPresent tag - Key: STR-373 URL: http://issues.apache.org/struts/browse/STR-373 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: other Platform: Other Reporter: tan, pow hwee Fix For: 1.1 Family I need to detect whether an error is present in ActionErrors, and saw this logic:messagesPresent tag available in your documentation. However, when I tried to use it, the tag is reported as not available. Looking at the logic.tld file also shows that it is not there. Am I missing something? Thanks. ph -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-316) UTF-16 format character decode error when html-form use enctype as multipart/form-data
[ http://issues.apache.org/struts/browse/STR-316?page=all ]
Don Brown closed STR-316:
-
Resolution: Fixed
UTF-16 format character decode error when html-form use enctype as
multipart/form-data
Key: STR-316
URL: http://issues.apache.org/struts/browse/STR-316
Project: Struts Action 1
Type: Bug
Components: Action
Versions: 1.0 Final
Environment: Operating System: All
Platform: PC
Reporter: Lee Sure
I want to devolop a chinese version web application use struts.
Last week, I had tested struts html-tags in weblogic server 6.0sp2. When I
used
struts-html tags like this:
html:form action=/testChinese.do ENCTYPE=multipart/form-data
method=post
html:text name=testForm property=text /
html:file name=testForm property=uploadFile /
,
I had found the chinese characters I got from struts-action all like ??.
As antitheses, I only used a html-text field to test like this:
html:form action=/testChinese.do method=post
html:text name=testForm property=text /
,
the result is OK.
Test programs lists:
//testForm.java
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.upload.FormFile;
import java.util.Collection;
public class TestForm extends ActionForm {
private String text;
private FormFile uploadFile;
//
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
public FormFile getUploadFile () {
return this.uploadFile;
}
public void setUploadFile (FormFile uploadFile) {
this.uploadFile = uploadFile;
}
public void reset(ActionMapping mapping, HttpServletRequest request) {
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
return null;
}
}
// testAction.java
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.upload.FormFile;
public final class TestAction extends Action
{
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
//response.setContentType( text/html; charset=GB2312 ) ;
System.out.println(start of TestAction);
TestForm testForm = (TestForm)form;
try {
String text = testForm.getText();
System.out.println(#27721;#23383; is + text);
FormFile file = testForm.getUploadFile();
if (file.getFileSize() 1024000) {
throw new
IOException(#25991;#20214;#36229;#36807;#19968;#20806;#23383;#33410;,#19981;#33021;#22788;#29702;!);
}
InputStream is = file.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String testStr = br.readLine();
System.out.println(get upload file, the first line is +
testStr);
} catch (Exception ex) {
System.out.println(TestAction has Exception: + ex);
}
return (mapping.findForward(back));
}
}
// test.jsp
%@ page contentType=text/html; charset=gb2312 %
%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
%@ taglib uri=/WEB-INF/struts-html.tld prefix=html %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
html:html locale=true
head
title#27721;#23383;#27979;#35797;/title
html:base/
meta http-equiv=Content-Type content=text/html; charset=gb2312
/head
body bgcolor=#FF topmargin=0 rightmargin=2% leftmargin=2%
bottommargin=0
!-- content:begin --
table width=100% border=0 cellspacing=0 cellpadding=0
tr
td width=5%nbsp;/td
td width=95% height=11
html:form action=/testChinese.do ENCTYPE=multipart/form-
data method=post
table width=100% border=1 cellspacing=0
cellpadding=0 bordercolorlight=#FF bordercolordark=#FF
tr
td height=5 colspan=2nbsp;/td
/tr
tr height=25
td
[jira] Closed: (STR-373) logic:messagesPresent tag
[ http://issues.apache.org/struts/browse/STR-373?page=all ] Don Brown closed STR-373: - Resolution: Fixed logic:messagesPresent tag - Key: STR-373 URL: http://issues.apache.org/struts/browse/STR-373 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0 Final Environment: Operating System: other Platform: Other Reporter: tan, pow hwee Fix For: 1.1 Family I need to detect whether an error is present in ActionErrors, and saw this logic:messagesPresent tag available in your documentation. However, when I tried to use it, the tag is reported as not available. Looking at the logic.tld file also shows that it is not there. Am I missing something? Thanks. ph -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-372) ResponseUtils.filter() does not encode the apostrophe character
[ http://issues.apache.org/struts/browse/STR-372?page=all ] Don Brown closed STR-372: - Resolution: Fixed ResponseUtils.filter() does not encode the apostrophe character --- Key: STR-372 URL: http://issues.apache.org/struts/browse/STR-372 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Jon Ribbens Fix For: 1.1 Family Attachments: patch ResponseUtils.filter() encodes , , and but not '. It is necessary to encode ' in cases where the output is being used as an attribute value enclosed by ' characters. ( is more usual but ' is equally valid and is certainly used sometimes.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1634) tiles:insert should pass flush attribute to JspWriter
[ http://issues.apache.org/struts/browse/STR-1634?page=all ] David Evans reopened STR-1634: -- tiles:insert should pass flush attribute to JspWriter --- Key: STR-1634 URL: http://issues.apache.org/struts/browse/STR-1634 Project: Struts Action 1 Type: Improvement Components: Tiles Versions: 1.1 Final Environment: Operating System: other Platform: All Reporter: Fabricio Voznika Assignee: Don Brown Priority: Minor Fix For: 1.3.0 Let's suppose I do a titles:insert page=/template_main.jsp flush=false ... When the code is executed, the method InsertHandler.doEndTag() (inner of InsertTag) is called. In the end, before all catches (line 881), after correctly testing for flush, doInclude() is called. It then calls TilesUtil.doInclude(), that calls TilesUtilImpl.doInclude(), that calls PageContext.include(String). According to the documentation (see bellow), this last method flushes the JspWriter. The current JspWriter out for this JSP is flushed as a side-effect of this call, prior to processing the include. The flush variable should be propagated to TilesUtilImpl.doInclude(), and PageContext.include(String, boolean) called. Always flushing, makes setting response headers, forwarding and error handling (forwarding) impossible to use together with tile. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-427) byte lost every 4096 bytes after a 0A
[ http://issues.apache.org/struts/browse/STR-427?page=all ] Don Brown reopened STR-427: --- Assign To: (was: Struts Developer Mailing List) byte lost every 4096 bytes after a 0A - Key: STR-427 URL: http://issues.apache.org/struts/browse/STR-427 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: Solaris Platform: Sun Reporter: Jessica Lin Fix For: 1.1 Family we use the file upload component to upload xml files. The xml files which are generated by VB XMLObjects has few enter(0A) between tags. for example, in IE we see tags like this: ?xml version=1.0 encoding=Shift_JIS? !DOCTYPE ITEMData SYSTEM ITEMData .dtd ITEMData ITEM NAMEABC/NAME IPAGE/ /ITEM /ITEMData but the file is like this: ?xml version=1.0 encoding=Shift_JIS? !DOCTYPE ITEMData SYSTEM ITEMData .dtd ITEMDataITEMNAMEABC/NAMEIPAGE//ITEM/ITEMData we found that there are some bytes lost in the xml file. Every byte lost is the one 4096 bytes after the lastest 0A, and right byte is replaced by a new 0A. So in the file, we lost a byte every 4096 bytes after a 0A, and got a new 0A. But this phenomenon does not happens every time. Even with the same file, sometime it happens, sometime it does not. We guess is it something about the readline() used in the component. Our project will release in March. Is it a bug in struts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-427) byte lost every 4096 bytes after a 0A
[ http://issues.apache.org/struts/browse/STR-427?page=all ] Don Brown closed STR-427: - Resolution: Fixed byte lost every 4096 bytes after a 0A - Key: STR-427 URL: http://issues.apache.org/struts/browse/STR-427 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: Solaris Platform: Sun Reporter: Jessica Lin Fix For: 1.1 Family we use the file upload component to upload xml files. The xml files which are generated by VB XMLObjects has few enter(0A) between tags. for example, in IE we see tags like this: ?xml version=1.0 encoding=Shift_JIS? !DOCTYPE ITEMData SYSTEM ITEMData .dtd ITEMData ITEM NAMEABC/NAME IPAGE/ /ITEM /ITEMData but the file is like this: ?xml version=1.0 encoding=Shift_JIS? !DOCTYPE ITEMData SYSTEM ITEMData .dtd ITEMDataITEMNAMEABC/NAMEIPAGE//ITEM/ITEMData we found that there are some bytes lost in the xml file. Every byte lost is the one 4096 bytes after the lastest 0A, and right byte is replaced by a new 0A. So in the file, we lost a byte every 4096 bytes after a 0A, and got a new 0A. But this phenomenon does not happens every time. Even with the same file, sometime it happens, sometime it does not. We guess is it something about the readline() used in the component. Our project will release in March. Is it a bug in struts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-501) Consultant addition
[ http://issues.apache.org/struts/browse/STR-501?page=all ] Don Brown reopened STR-501: --- Assign To: (was: Struts Developer Mailing List) Consultant addition --- Key: STR-501 URL: http://issues.apache.org/struts/browse/STR-501 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0.2 Environment: Operating System: other Platform: Other Reporter: wchao Fix For: 1.1 Family I'd like to add my firm under the list of consultants because we develop solutions in Struts. The name is Caravel Technologies. The URL is www.caraveltech.com. The contact should be Wellie Chao [EMAIL PROTECTED]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-501) Consultant addition
[ http://issues.apache.org/struts/browse/STR-501?page=all ] Don Brown closed STR-501: - Resolution: Fixed Consultant addition --- Key: STR-501 URL: http://issues.apache.org/struts/browse/STR-501 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.0.2 Environment: Operating System: other Platform: Other Reporter: wchao Fix For: 1.1 Family I'd like to add my firm under the list of consultants because we develop solutions in Struts. The name is Caravel Technologies. The URL is www.caraveltech.com. The contact should be Wellie Chao [EMAIL PROTECTED]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-575) Serializability issues in ActionServlet/RequestProcessor
[ http://issues.apache.org/struts/browse/STR-575?page=all ] Don Brown reopened STR-575: --- Assign To: (was: Struts Developer Mailing List) Serializability issues in ActionServlet/RequestProcessor Key: STR-575 URL: http://issues.apache.org/struts/browse/STR-575 Project: Struts Action 1 Type: Bug Components: Action Versions: Nightly Build Environment: Operating System: other Platform: Other Reporter: Andre Beskrowni Attachments: struts.diff.txt We frequently get NotSerializableExceptions in WLS 6.1 for the following classes: ActionServlet RequestProcessor MessageResources (we also get them for a couple of tiles classes too, but i'll submit that separately...) in some cases, this is easy to resolve, but in others --- not as easy. In MessageResources, if you just make the log attribute transient, you're done. You have to do the same for ActionServlet, but that's not enough. ActionServlet also holds onto a RequestProcessor attribute and RequestProcessor isn't Serializable. i'm not smart enough to know for sure if you can just make the RequestProcessor attribute transient here, but if you make it Serializable, it looks like then you'll have to make Action serializable as well, which may not be a desired consequence. Just for the reference, an example of one of the exception stacks we're seeing is included below: java.io.NotSerializableException: org.apache.struts.action.RequestProcessor at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper .java:92) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper .java:64) at weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppSer vletContext.java:302) at org.apache.struts.action.ActionServlet.getRequestProcessor(ActionServ let.java:759) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:116 1) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:453) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe rvletContext.java:2456) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm pl.java:2039) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-584) RequestProcessor doesn't uncast the Request properly (was Fileupload with Bea Weblogic 6.1 Sp2 throws an exception
[ http://issues.apache.org/struts/browse/STR-584?page=all ]
Don Brown closed STR-584:
-
Resolution: Fixed
RequestProcessor doesn't uncast the Request properly (was Fileupload with Bea
Weblogic 6.1 Sp2 throws an exception
--
Key: STR-584
URL: http://issues.apache.org/struts/browse/STR-584
Project: Struts Action 1
Type: Bug
Components: Action
Versions: 1.1 Beta 1
Environment: Operating System: All
Platform: All
Reporter: Robby Reinicke
Fix For: 1.1 Family
Attachments: RequestProcessor.diff, RequestProcessor.patch.txt
Hi,
when you use struts in combination with a Weblogic servlet container and
you would like to use multipart forms for a file upload, you get a
500 error :o( .
But it's easy to fix !
In package org.apache.struts.action class RequestProcessor method
doForward(...) add the follwing code as the first lines:
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}
Reason: Bea checks the request like this:
if(servletrequest instanceof HttpServletRequestWrapper) {
} else {
throw new ServletException(Original request not available);
}
Ciao... R. Reinicke
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-72) Clean Way to Add Parameters to Redirecting Forward
[ http://issues.apache.org/struts/browse/STR-72?page=all ] David Evans reopened STR-72: Clean Way to Add Parameters to Redirecting Forward -- Key: STR-72 URL: http://issues.apache.org/struts/browse/STR-72 Project: Struts Action 1 Type: Improvement Components: Extras Versions: Nightly Build Environment: Operating System: All Platform: PC Reporter: Mike McCallister Assignee: Don Brown Priority: Minor Fix For: 1.2 Family Attachments: Action.java.patch, ActionRedirect.java, ActionRedirect.java, ActionRedirect.java, ControllerConfig.java.patch, Globals.java.patch, RequestProcessor.java.patch, StrutsUtil.java, TestActionRedirect.java, TestActionRedirect.java, TestActionRedirect.java, TestActionRedirect.properties, TestActionRedirect2.properties, build-tests.xml.patch, struts-config_1_2.dtd.patch It would be nice if ActionForward provided a clean way to attach URL encoded parameters (for when the forward mapping of success has redirect=true). Here is what I do now: StringBuffer newPath = new StringBuffer(mapping.findForward(success).getPath()); newPath.append(?coreId=); newPath.append(ResponseUtils.filter(reqform.getCoreId())); return (new ActionForward(newPath.toString(), true)); It would be nice if something like this was possible instead: return (mapping.findForward(success).addParameter(coreId, reqform.getCoreId())); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-599) [PATCH] 0 should be a valid float
[ http://issues.apache.org/struts/browse/STR-599?page=all ]
Don Brown reopened STR-599:
---
Assign To: (was: Struts Developer Mailing List)
[PATCH] 0 should be a valid float
-
Key: STR-599
URL: http://issues.apache.org/struts/browse/STR-599
Project: Struts Action 1
Type: Bug
Components: Action
Versions: Nightly Build
Environment: Operating System: All
Platform: All
Reporter: Jose Quinteiro
Fix For: 1.1 Family
Current validator-rules.xml does not validate 0 as a float. Here is a patch:
Index: conf/share/validator-rules.xml
===
RCS file: /home/cvspublic/jakarta-struts/conf/share/validator-rules.xml,v
retrieving revision 1.2
diff -r1.2 validator-rules.xml
379c379
if (!iValue) {
---
if( isNaN(iValue) ) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-610) ClassNotFoundException with Tomcat 3.x
[ http://issues.apache.org/struts/browse/STR-610?page=all ] Don Brown reopened STR-610: --- Assign To: (was: Struts Developer Mailing List) ClassNotFoundException with Tomcat 3.x -- Key: STR-610 URL: http://issues.apache.org/struts/browse/STR-610 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: All Platform: PC Reporter: Joerg Friedrich Fix For: 1.1 Family There appears to be a problem with the class loaders in Struts 1.1 Beta 1 and the Commons libraries. When loading a servlet action (org.apache.struts.action.ActionServlet) I get the following error on Tomcat 3.2.1 and Tomcat 3.2.3: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.LogFactoryImpl The identical application works fine on Tomcat 4.0. There are some hints in the mailing lists on that problem but no real suggestion of a good workaround or fix. Thank you for looking into this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-599) [PATCH] 0 should be a valid float
[ http://issues.apache.org/struts/browse/STR-599?page=all ]
Don Brown closed STR-599:
-
Resolution: Fixed
[PATCH] 0 should be a valid float
-
Key: STR-599
URL: http://issues.apache.org/struts/browse/STR-599
Project: Struts Action 1
Type: Bug
Components: Action
Versions: Nightly Build
Environment: Operating System: All
Platform: All
Reporter: Jose Quinteiro
Fix For: 1.1 Family
Current validator-rules.xml does not validate 0 as a float. Here is a patch:
Index: conf/share/validator-rules.xml
===
RCS file: /home/cvspublic/jakarta-struts/conf/share/validator-rules.xml,v
retrieving revision 1.2
diff -r1.2 validator-rules.xml
379c379
if (!iValue) {
---
if( isNaN(iValue) ) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-610) ClassNotFoundException with Tomcat 3.x
[ http://issues.apache.org/struts/browse/STR-610?page=all ] Don Brown closed STR-610: - Resolution: Fixed ClassNotFoundException with Tomcat 3.x -- Key: STR-610 URL: http://issues.apache.org/struts/browse/STR-610 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: All Platform: PC Reporter: Joerg Friedrich Fix For: 1.1 Family There appears to be a problem with the class loaders in Struts 1.1 Beta 1 and the Commons libraries. When loading a servlet action (org.apache.struts.action.ActionServlet) I get the following error on Tomcat 3.2.1 and Tomcat 3.2.3: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.LogFactoryImpl The identical application works fine on Tomcat 4.0. There are some hints in the mailing lists on that problem but no real suggestion of a good workaround or fix. Thank you for looking into this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-686) Validator is not available under sub-application
[ http://issues.apache.org/struts/browse/STR-686?page=all ] Don Brown reopened STR-686: --- Assign To: (was: Struts Developer Mailing List) Validator is not available under sub-application Key: STR-686 URL: http://issues.apache.org/struts/browse/STR-686 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Gen Kagawa Fix For: 1.1 Family Attachments: StrutsValidatorUtil.patch, StrutsValidatorUtil.patch, validator-1.1-compatability.patch It seems that Validator does not work under sub-application of struts1.1b . I tried to make Validator Plug-In in each struts-config.xml of sub-applications, but it's failed. My Idea is follows: 1. Modify ValidatorPlugIn.init() to set resources to ServletContext with 'prefix' of sub-application. 2. Modify StrutsValidatorUtil.getValidatorResources() to get resources from ServletContext by 'prefix' of sub-application. Some parameters may have to change to do this. I wish to be fixed in Struts1.1b2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-686) Validator is not available under sub-application
[ http://issues.apache.org/struts/browse/STR-686?page=all ] Don Brown closed STR-686: - Resolution: Fixed Validator is not available under sub-application Key: STR-686 URL: http://issues.apache.org/struts/browse/STR-686 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 2 Environment: Operating System: All Platform: All Reporter: Gen Kagawa Fix For: 1.1 Family Attachments: StrutsValidatorUtil.patch, StrutsValidatorUtil.patch, validator-1.1-compatability.patch It seems that Validator does not work under sub-application of struts1.1b . I tried to make Validator Plug-In in each struts-config.xml of sub-applications, but it's failed. My Idea is follows: 1. Modify ValidatorPlugIn.init() to set resources to ServletContext with 'prefix' of sub-application. 2. Modify StrutsValidatorUtil.getValidatorResources() to get resources from ServletContext by 'prefix' of sub-application. Some parameters may have to change to do this. I wish to be fixed in Struts1.1b2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1084) Nested tags picks up wrong bean for values
[ http://issues.apache.org/struts/browse/STR-1084?page=all ]
David Evans reopened STR-1084:
--
Assign To: (was: James Turner)
Nested tags picks up wrong bean for values
--
Key: STR-1084
URL: http://issues.apache.org/struts/browse/STR-1084
Project: Struts Action 1
Type: Bug
Components: Taglibs
Versions: 1.1 Beta 3
Environment: Operating System: All
Platform: All
Reporter: David Morris
Fix For: 1.1 Family
I located the source of the problem, which is caused
by a change to the nested tags. The code causing the error is this block
found in the NestedPropertyHelper.getNestedNameProperty method.
The name property for any tag that extends
org.apache.struts.taglib.html.BaseFieldTag
is initialized to a constant value of
Constants.BEAN_KEY. That means the test for
null is never met so the innermost nested
tag's (which is the nested:text tag in this case)
name is used in some cases.
Removing this code should fix my case, but
I suspect that there was a reason for this
change, which was made shortly after beta 2
was released. Here is a patch that is less
drastic than the removal. This patch makes
the minimal change, but there are still cases
in the existing code where errors are not
dealt with that should probably be fixed.
Index: NestedPropertyHelper.java
===
RCS file: /home/cvspublic/jakarta-
struts/src/share/org/apache/struts/taglib/nested/NestedPropertyHelper.java,v
retrieving revision 1.11
diff -u -r1.11 NestedPropertyHelper.java
--- NestedPropertyHelper.java 16 Nov 2002 07:07:07 - 1.11
+++ NestedPropertyHelper.java 4 Jan 2003 07:14:13 -
@@ -65,6 +65,7 @@
import javax.servlet.jsp.tagext.Tag;
import org.apache.struts.taglib.html.FormTag;
+import org.apache.struts.taglib.html.Constants;
/** A simple helper class that does everything that needs to be done to get
the
* nested tag extension to work. Knowing what tags can define the lineage of
@@ -211,11 +212,17 @@
Tag namedTag = (Tag)tag;
// see if we're already in the right location
+String defaultName = null;
if (namedTag instanceof NestedNameSupport) {
String name = ((NestedNameSupport)namedTag).getName();
- // return if we already have a name
+ // return if we already have a name and not just default
if (name != null) {
- return name;
+if (name.equals(Constants.BEAN_KEY)) {
+defaultName = name;
+}
+else {
+return name;
+}
}
}
@@ -228,7 +235,11 @@
!(namedTag instanceof NestedParentSupport) );
if (namedTag == null) {
- // need to spit some chips
+// Return default name because parent is not more specific.
+if (defaultName != null) {
+return defaultName;
+}
+// need to spit some chips
}
String nameTemp = null;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-726) PATCH: ValidatorUtils can't handle StringArrays
[ http://issues.apache.org/struts/browse/STR-726?page=all ] Don Brown closed STR-726: - Resolution: Fixed PATCH: ValidatorUtils can't handle StringArrays --- Key: STR-726 URL: http://issues.apache.org/struts/browse/STR-726 Project: Struts Action 1 Type: Bug Components: Action Versions: Nightly Build Environment: Operating System: All Platform: All Reporter: James Turner Fix For: 1.1 Family Attachments: ValidatorUtil.java.diff ValidatorUtils currently uses the property handed in from the field to retrieve the value to validate. Alas, it doesn't work for an indexed string value as generated by Validator. Luckily, validator hands the value in as a String on the bean property for indexed strings, so there's no need to look it up anyway. Added test to see if the bean argument is a string or null (it's the form object if the call was made from a non-indexed value), and use the null or string value instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-798) MessageResources is not module aware
[ http://issues.apache.org/struts/browse/STR-798?page=all ]
Don Brown reopened STR-798:
---
MessageResources is not module aware
Key: STR-798
URL: http://issues.apache.org/struts/browse/STR-798
Project: Struts Action 1
Type: Bug
Components: Action
Versions: Nightly Build
Environment: Operating System: other
Platform: All
Reporter: Alex Kwan
Assignee: Martin Cooper
Fix For: 1.2 Family
Suppose we define a sub app in web.xml as below
...
init-param
param-nameconfig/param-name
param-value/WEB-INF/configs/default/struts-config.xml/param-value
/init-param
init-param
param-nameconfig/sample/param-name
param-value/WEB-INF/configs/sample/struts-config.xml/param-value
/init-param
...
and in the default struts-config.xml file,
we add the following message resouces
...
message-resources parameter=DefaultMessageResources/
message-resources key=IMAGE_RESOURCES_KEY
parameter=DefaultImageResources/
...
now we create two message resources in the sub app sample's struts-config.xml
...
message-resources parameter=SampleMessageResources/
message-resources key=IMAGE_RESOURCES_KEY
parameter=SampleImageResources/
...
then we create a test.jsp in path /webroot/sample/
the file contains the following line
...
bean:message key=test/
...
html:img bundle=IMAGE_RESOURCES_KEY pageKey=test.img/
...
the problem is the message tag renders fine but the img tag came out with
something like img src=http://hostaddress/contextPath/samplenull
I checked the source of class ImgTag and found it get the src path through
...
return (request.getContextPath() + config.getPrefix() +
RequestUtils.message(pageContext, getBundle(), getLocale(),
this.pageKey));
...
but in RequestUtils.message method
// Look up the requested MessageResources
if (bundle == null) {
bundle = Action.MESSAGES_KEY;
resources = (MessageResources)
pageContext.getAttribute(bundle, PageContext.REQUEST_SCOPE);
}
if (resources == null) {
resources = (MessageResources)
pageContext.getAttribute(bundle,
PageContext.APPLICATION_SCOPE);
}
it simply first check for the default message then go to get bundle int
application scope.
so if i want use the img tag, I must specify the bundle as
bundle=IMAGE_RESOURCES_KEY/sample
Now my question is whether we can just use the img tag as the message tag,
like
bundle=IMAGE_RESOURCES_KEY
it's much graceful than bundle=IMAGE_RESOURCES_KEY/sample
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (STR-723) PropertyMessageResources loading resources from the wrong ClassLoader
[ http://issues.apache.org/struts/browse/STR-723?page=all ] Don Brown closed STR-723: - Resolution: Fixed PropertyMessageResources loading resources from the wrong ClassLoader - Key: STR-723 URL: http://issues.apache.org/struts/browse/STR-723 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: other Platform: All Reporter: James Farley Fix For: 1.1 Family Attachments: PropertyMessageResources.java.diff At my company, we have decided to deploy the Struts JAR into Tomcat's shared classloader (the lib/ directory in the 4.0.x series) due to a number of classes that we will be sharing. Everything works fine *except* for the loading of the application's resource file. The reason is this: the PropertyMessageResources source explicitly attempts to load the resources via the ClassLoader associated with the class, not the thread. This means if your ApplicationResources are deployed in a webapp, but the struts.jar is in the shared directory, the code will *not* be able to find the properties file. The fix is to use the context ClassLoader associated with the current thread of execution. This way, the struts.jar will be able to find the resources file whether it is deployed in a WAR or is shared globally in an application server. The patch is attached to the bug. (As an aside - why does the PropertyMessageResources go through all the explicit trouble of loading the file itself, when it could just use the ResourceBundle.getBundle() method?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-726) PATCH: ValidatorUtils can't handle StringArrays
[ http://issues.apache.org/struts/browse/STR-726?page=all ] Don Brown reopened STR-726: --- Assign To: (was: Struts Developer Mailing List) PATCH: ValidatorUtils can't handle StringArrays --- Key: STR-726 URL: http://issues.apache.org/struts/browse/STR-726 Project: Struts Action 1 Type: Bug Components: Action Versions: Nightly Build Environment: Operating System: All Platform: All Reporter: James Turner Fix For: 1.1 Family Attachments: ValidatorUtil.java.diff ValidatorUtils currently uses the property handed in from the field to retrieve the value to validate. Alas, it doesn't work for an indexed string value as generated by Validator. Luckily, validator hands the value in as a String on the bean property for indexed strings, so there's no need to look it up anyway. Added test to see if the bean argument is a string or null (it's the form object if the call was made from a non-indexed value), and use the null or string value instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-1034) [taglib] Use attribute 'id' instead of 'name' in html:form-Tag
[ http://issues.apache.org/struts/browse/STR-1034?page=all ] David Evans reopened STR-1034: -- Assign To: (was: Struts Developer Mailing List) [taglib] Use attribute 'id' instead of 'name' in html:form-Tag -- Key: STR-1034 URL: http://issues.apache.org/struts/browse/STR-1034 Project: Struts Action 1 Type: Improvement Components: Taglibs Versions: Nightly Build Environment: Operating System: All Platform: All Reporter: Gerhard Bloch Priority: Minor Fix For: 1.2 Family Attachments: struts_xhtml_form_patch.tar.gz The html:form-Tag creates a 'name' attribute which is used by the focus-Script. However in XHTML 1.0 Strict there is no such attribute defined for the 'form' Tag. Use of the attribute 'id' could solve this issue. However there might be a possible danger because id is declared to be an ID and enforces document-scope uniqueness. In contrast 'name is declared to be an NMTOKEN which doesn't enforce this requirement. The use of 'id' will enhance conformance to the standard. As is, the document has to be declared XHTML 1.0 Transitional if the html:form-Tag is used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (STR-1084) Nested tags picks up wrong bean for values
[ http://issues.apache.org/struts/browse/STR-1084?page=all ]
David Evans resolved STR-1084:
--
Resolution: Fixed
Nested tags picks up wrong bean for values
--
Key: STR-1084
URL: http://issues.apache.org/struts/browse/STR-1084
Project: Struts Action 1
Type: Bug
Components: Taglibs
Versions: 1.1 Beta 3
Environment: Operating System: All
Platform: All
Reporter: David Morris
Fix For: 1.1 Family
I located the source of the problem, which is caused
by a change to the nested tags. The code causing the error is this block
found in the NestedPropertyHelper.getNestedNameProperty method.
The name property for any tag that extends
org.apache.struts.taglib.html.BaseFieldTag
is initialized to a constant value of
Constants.BEAN_KEY. That means the test for
null is never met so the innermost nested
tag's (which is the nested:text tag in this case)
name is used in some cases.
Removing this code should fix my case, but
I suspect that there was a reason for this
change, which was made shortly after beta 2
was released. Here is a patch that is less
drastic than the removal. This patch makes
the minimal change, but there are still cases
in the existing code where errors are not
dealt with that should probably be fixed.
Index: NestedPropertyHelper.java
===
RCS file: /home/cvspublic/jakarta-
struts/src/share/org/apache/struts/taglib/nested/NestedPropertyHelper.java,v
retrieving revision 1.11
diff -u -r1.11 NestedPropertyHelper.java
--- NestedPropertyHelper.java 16 Nov 2002 07:07:07 - 1.11
+++ NestedPropertyHelper.java 4 Jan 2003 07:14:13 -
@@ -65,6 +65,7 @@
import javax.servlet.jsp.tagext.Tag;
import org.apache.struts.taglib.html.FormTag;
+import org.apache.struts.taglib.html.Constants;
/** A simple helper class that does everything that needs to be done to get
the
* nested tag extension to work. Knowing what tags can define the lineage of
@@ -211,11 +212,17 @@
Tag namedTag = (Tag)tag;
// see if we're already in the right location
+String defaultName = null;
if (namedTag instanceof NestedNameSupport) {
String name = ((NestedNameSupport)namedTag).getName();
- // return if we already have a name
+ // return if we already have a name and not just default
if (name != null) {
- return name;
+if (name.equals(Constants.BEAN_KEY)) {
+defaultName = name;
+}
+else {
+return name;
+}
}
}
@@ -228,7 +235,11 @@
!(namedTag instanceof NestedParentSupport) );
if (namedTag == null) {
- // need to spit some chips
+// Return default name because parent is not more specific.
+if (defaultName != null) {
+return defaultName;
+}
+// need to spit some chips
}
String nameTemp = null;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (STR-723) PropertyMessageResources loading resources from the wrong ClassLoader
[ http://issues.apache.org/struts/browse/STR-723?page=all ] Don Brown reopened STR-723: --- Assign To: (was: Struts Developer Mailing List) PropertyMessageResources loading resources from the wrong ClassLoader - Key: STR-723 URL: http://issues.apache.org/struts/browse/STR-723 Project: Struts Action 1 Type: Bug Components: Action Versions: 1.1 Beta 1 Environment: Operating System: other Platform: All Reporter: James Farley Fix For: 1.1 Family Attachments: PropertyMessageResources.java.diff At my company, we have decided to deploy the Struts JAR into Tomcat's shared classloader (the lib/ directory in the 4.0.x series) due to a number of classes that we will be sharing. Everything works fine *except* for the loading of the application's resource file. The reason is this: the PropertyMessageResources source explicitly attempts to load the resources via the ClassLoader associated with the class, not the thread. This means if your ApplicationResources are deployed in a webapp, but the struts.jar is in the shared directory, the code will *not* be able to find the properties file. The fix is to use the context ClassLoader associated with the current thread of execution. This way, the struts.jar will be able to find the resources file whether it is deployed in a WAR or is shared globally in an application server. The patch is attached to the bug. (As an aside - why does the PropertyMessageResources go through all the explicit trouble of loading the file itself, when it could just use the ResourceBundle.getBundle() method?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
