Re: ASL 2.0
If I can be of assistance, let me know. Paul Sundling David Graham wrote: I attempted to apply the patches but Eclipse wouldn't cooperate. I don't have any other cvs tools on my windows box, which is the only one with Struts development setup at the moment. David --- Ted Husted [EMAIL PROTECTED] wrote: Would anyone have a chance to apply Paul's patch this afternoon? http://issues.apache.org/bugzilla/show_bug.cgi?id=27137 I'm out of town and this might be a bear for me to commit over a 28.8 modem connection :) Otherwise, I'll try to do it later tonight. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASL 2.0
I used the java tool and even made some fixes. I can run that again too and resubmit a patch. Let me know. Paul [EMAIL PROTECTED] wrote: An alternative is to directly run the python scripts, it's probably easier than applying the patch. I could do that. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Sunday, March 7, 2004 10:08 PM To: 'Struts Developers List' Subject: Re: ASL 2.0 I attempted to apply the patches but Eclipse wouldn't cooperate. I don't have any other cvs tools on my windows box, which is the only one with Struts development setup at the moment. David --- Ted Husted [EMAIL PROTECTED] wrote: Would anyone have a chance to apply Paul's patch this afternoon? http://issues.apache.org/bugzilla/show_bug.cgi?id=27137 I'm out of town and this might be a bear for me to commit over a 28.8 modem connection :) Otherwise, I'll try to do it later tonight. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 is tagged and frozen
Ted, I want to start off by saying I look up to you and respect you. I don't consider myself an equal to you or several of the other giants on this project, but I do consider myself part of this community now. In fact, earlier today I changed my email address from [EMAIL PROTECTED] to [EMAIL PROTECTED] ;) The way I see it, there is a natural order of things. Normally you start out as a user, then move to a lurker on the dev list. You start to become active on the list. Then you start helping in little ways as a contributer and for the few elite chosen few, the top status as a committer. My personal plan was to take care of some grunt work like author tags/licenses/fixing common maven report errors to make them more usable. Some of that I've already done. Then I planned to specialize in adding unit tests, and as I become more familiar with the inner source code, to make more core contributions. Someday I might even be accepted as a committer. Not to be dramatic, but removing the author tags from the volunteers page itself sends the message that non-committers are an even less important part of the community. There's largely some truth to that, but tt would be disappointing to see the contributors list go away. It's nice to get acknowledgement in CVS and on most of my of patches (but not all), I did get that. As for the legal issues. The Committers being actors is true wether or not people are listed on the page. As for as a list accumulating over decades, the list could always be version(minor or major) specific. Taking a step back, here is how some other projects are dealing with this issue: Tomcat: they don't even deal with such a page and point instead to the overall jakarta whoweare.html which lists committers and project management committee(PMC) members. (http://jakarta.apache.org/site/whoweare.html) Jakarta Logging: list PMC members and committers, with pictures even. I guess jboss isn't the only one to do that. :) (http://logging.apache.org/site/who-we-are.html) Ant: PMC committers So perhaps I'm a singular voice in the wilderness, but removing the author tags from the volunteer page seems to be a decision important enough that a vote might be in order. Regardless of the outcome, I'll still volunteer to take care of it and submit a patch. I would however recommend that if the changes are made, the page be retitled, from volunteers to whoweare. After seeing other projects, I can definitely see the other side on this one. The bottom line is that I like feeling a part of this project and the only difference is how easy it to defend that position to myself or outsiders. So I'll list the possible options(perhaps there are others I haven't realized): 1] continue maintining volunteers with list of contributers like now instead of author tags a] leave sorted as now b]move list of sourcedoc contributers to bottom of page. below commiters list description c]move contributers list to a seperate page that is only linked to from bottom of the page. 2] remove source document contributers from voluntters page a] leaving page called volunteers b] changing page to whoweare 3] remove page entirely and point the link to the jakarta whoweare page Paul Sundling Ted Husted wrote: On Mon, 23 Feb 2004 11:23:08 -0800, Paul Sundling wrote: I should probably still remove author tags from the docs and consolidate those into the volunteers page also. I'm afraid that our volunteers page is subject to the same considerations as the author tags. :( * Low hanging suit. In the unlikely event of a law suit, this is a (very) convenient list of parties to join to the action. We may think it's silly, but it is what an attorney would do. Each of these people would then be responsible for having themselves severed from the suit. (Guilty until proven innocent, I'm afraid.) The ASF would do what they could, but resources are limited; we shouldn't tempt fate. * No strings attached. An important ASF principle is that all the code and documentation belong to the Foundation and its Community. Tags and other credits tend to imply some people own more of the resources than others. When a resource is donated to the foundation, we need to emphasize that it belongs to the Foundation, free and clear. * Duty now for the future. ASF projects are meant to live for decades. The current list is already lengthy. What will it look like ten years from now? How much of the contributions of those we list today will really be part of the product then? Tags and lists like these cannot be sustained for the full life of an Apache product. Sadly, we should probably trim the Who We Are page down to the list of Struts Committers who are members of the Jakarta PMC, since these individuals are the legal representatives of the Foundation. In this context, the Struts Committee Members would be presented as the decision-makers rather than the authors. (Technically, what
Re: 1.2.0 is tagged and frozen
As an aside to Joe, the person who was bringing up the licenses a couple weeks ago was me. :) From what I read on the instructions for the license file stuff I also need to update the xml that is transformed into our documentation and add a comment to that as well. I'll submit another patch for the contrib. Given how many pieces I had to break the main src patch into, it might be less confusing for me to open seperate bugzilla entries for the docs and contrib. Anyone have any thoughts on that? Do you think we need to go as far as properties files? Then there's stuff like stuts-config I guess it should have the header too. It's not as onerous with the new license at least. I should probably still remove author tags from the docs and consolidate those into the volunteers page also. I volunteer to take care of that. Several weeks ago I thought we were closer than we were to the 1.2 release and thought it might be a good idea to wait until after the release to make sweeping changes like those that touched a lot of files. The only @author tags in java source are in contrib and org.apache.struts.webapp.upload.UploadAction is the only class in the core distrubution with an author tag. It was added after I swept the main source. I am generally pretty detailed. :) So I'm raring to go on those. Let me know when I can start working on patches for these items. Paul Sundling After 1.2.0 is out of the gate, we can apply Paul's license patches, as you suggest. Per Greg's board summary, we'll want to make sure we have the license on all applicable files. Also, since the board is now officially discouraging the use of @author tags, I'd like to see us remove those too. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
I woke up earlier than planned (I'm on a strange sleep schedule) and Robert Leland got me a copy of the tools, which saved me a bunch of time since my own tool was only 40% done. I used the java one, since python is the one LAMP language I don't know. I fixed one of the problems in the java tool README and another not mentioned. I still have to test the CheckStyle maven reports and read and/or parse through the 38K line patch file to make sure everything is OK. I estimate I'll finish about 5:30pm PST today, so unless the midnight my time is england or something I should finish well before the cutoff, leaving some a couple hours for a committer to check it out. Paul Sundling Martin Cooper wrote: -Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 7:52 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Thanks for doing this, Paul. One caveat: The tag/freeze for 1.2.0 happens tonight at midnight my time. Since there are often a few tweaks that happen after the tag and before the release itself, you might want to hold off until the release is uploaded (or I send a Houston, we have lift-off message) before updating your source tree. (It turns out that I have a social engagement today also, so I can't take care of this before tag/freeze either.) -- Martin Cooper Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [VOTE] 1.2.0 Release Plan
David Graham, I finished 3 minutes ahead of my estimated time. :) Unfortunately, it's taking forever (30 minutes so far) to upload the patch file, which is just shy of 2 megs. Would it speed things up any to send you a copy directly, while it's uploading? I thought I'd ask since we're on a tight deadline. Paul Sundling David Graham wrote: Thanks for volunteering! I will review and apply the patch once it's entered in bugzilla. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Besides changing header, there's also maintaining copyrights and moving them to a new location and then updating a Checkstyle version of the license. I did the last major license update and I'd be willing to do it as well this weekend. Just let me know. Paul Sundling Karr, David wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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: html:javascript behavior when form is not found
I'm not sure if struts itself has a design philosophy, but java itself has the fail fast philosophy. Iterators are one of the most widely cited examples. If something is wrong you want to fail as quickly as possible. A developer should be made aware of the mistake. Leaving a comment is like going half way. As long as the exception message can point them to the error, I'd have a strong preference for that. Paul Joe Germuska wrote: Right now, if you accidentally enter a bogus form name in the html:javascript tag, it omits the wrapping script tags, but prints all the javascript anyway. This doesn't seem right, but for some reason I have a feeling that the solutions I'm thinking of are a bit contentious, so rather than just change it, I thought I'd test the waters. My first thought was to print an HTML comment, something like !-- No form 'formName' found in 'formSet' -- But I think some people might not like that. Alternatives include throwing a JSPException; logging a warning and returning quietly, or doing something more in-your-face that would actually be visible, as opposed to in a comment. Part of me really likes the last because this is something that should only ever happen during development time, and the current spew of javascript is certainly in-your-face, but... Anyway, I don't really have a strong feeling about it. If no one weighs in, I'll probably stick with the comment, but I'll take any other direction. Hopefully the direction will come soon, though, because I'm also going to fix the tag class to escape error messages that contain quote-characters, and I'd just as soon commit 'em both at once. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
This looks like fun. I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? I'd be willing to take a whack at this one. Should this wait until after 1.2 so that can be wrapped up? I've been putting some other minor stuff on hold that I wanted to mention until after the release. If sizeKey was added to html:img, this brings up an issue. In the many places where we have sizes, there is not a key version of it. Text attributes like alt and title have resource versions like altKey and titleKey. Number attributes like size, width and height do not. While it's not a common thing to need varied sizes for numerical values, it's very plausible. Is it worth complicating the AI? Paul Sundling [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26647 srcKey in html:img/ tag needs matching size keys. On high-traffic web sites it is necessary to add the height and width of any image to allow for faster and more predictable loading. Under these circumstances, it is very difficult to manage the images using the srcKey attribute since the sizes must be either hard-coded into the tag or created using some type of obtuse code to populate the boxes. It would be much more desirable to have a sizeKey attribute where a height/width of an item would be entered into a property file in a comma delimited form (or other agreed upon format): in the property file myImage.image = /images/someFooImage.jpg myImage.image.size = 180,160 The JSP img tag would look like: html:img srcKey=myImage.image sizeKey=myImage.image.size/ We are moving a high-traffic site to struts (10-12+ million hits monthly) and this has been a thorn in our side. - 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: Clean Up conf/share
David Graham wrote: --- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd tiles-config.dtd -- This is for pre struts tiles. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd I agree that most of these should be removed but I think the webapp dtds are used when Struts uses Digester to parse web.xml. David I'm not the struts gurus that many of you are, but let me ask innocent questions for my own enlightment. If 1.1 is supporting 2.2, why do we have 2.3 dtd also. Since 2.4 uses XML schemas instead of DTD, has that been addressed? Granted, almost nothing changed from servlet 2.3 to 2.4, so DTD for 2.3 should pretty much work. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
Joe Germuska wrote: At 1:36 PM +1300 2/4/04, [EMAIL PROTECTED] wrote: Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... height and width are not valid attributes of the input tag: see http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Joe I can't say I'm surprised to hear that since it wasn't in my little book. At the same time, if a given attribute is not part of the official W3C HTML spec, does that mean we shouldn't support the feature if there is browser support for it? This is more a philosophical issue on wether you're supporting the HTML standard, or the browser implementations of the standard. Is there a project stance on that? Two main browsers since version 4 is pretty good support. If it's supported even in Safari and Opera or other, less common browsers, then I would say that's wide enough browser support to definitely consider. Of course, that's irrelevant if we're coding to spec and not implementation. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/tag-doc/src/java/org/apache/struts/taskdefs EnhMatchingTask.java TaglibDoc.java TaglibReport.java Util.java
Sorry about that, I was going to take care of that, but I wanted to ask if the authors should be added to the volunteers page with the main list or in a seperate section and wasn't going to get to it until tomorrow. :( Paul Sundling [EMAIL PROTECTED] wrote: Log: Remove @author javadoc tags from contrib classes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the different parameter counts?
I'd be interested in creating a patch for that. I always thought it was abitrary having some number of arguments like that myself. :) I think David is right on needing the single Object version, which is probably pretty common. To imagine why, just remember when sun tried to deprecate ServletRequest().getParameter(). I'll be busy all this week, but I could attempt it next week. At that point I'll also send an update on some other minor stuff I'd volunteered to do and any related feedback I needed. Paul Sundling Larry Meadors wrote: Other than some confusion, it is not a big deal, but it seems odd to me that they are different. Am I missing something? Is there a reason for not adding the five parameter version to the MessageResources method? IMO, there should be 3 versions of the method: accepting no replacement args, accepting one replacement arg, accepting an array of replacement args. The 4 or 5 arg methods seem arbitrary. I think you are right and that seems like a simple solution. But I wonder if even the one replacement arg is worth the extra code. The tag always calls the array version of the method, and the extra parameters to getMessage() buy you nothing because the methods simply convert the parameters to arrays, which can be done in-line anyway! :-) Clearly, it is not a pressing issue because it works. I think the tag is fine because it can be messy to pass arrays in jsp, but these two methods are the only ones that are actually needed: - getMessage(String, Object[]) - getMessage(Locale, String, Object[]) The rest is fluff and IMO should be deprecated in 1.2 and removed in the next release. ;-) Larry - 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]
Patch ready
It was quite a bit more work than I initially anticipated, but I think I did the right thing to take Martin Cooper's suggestion to take option 2. So after all that hard work, anyone want to check it out and commit? :) This was a lot bigger than the @author patch. Paul Sundling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26077] - Checkstyle reports -Licenses incorrect
First of all, it's done (other than 4 files), touching about 470 source files. It's not just formatting, but making it mostly consistent. The dates have to be left inconsistent and everything else made consistent. Even if that's a good approach, why redo it again? Maybe that can be used for the tabs issue. There's already a bunch of other solutions proposed on that one. If jalopy is made to format code to a specification and CheckStyle is to check if you formatted code to a spec, why not combine the tools. It could be like fsck, where it comes across errors and then you just choose Y and it fixes the problem for you. :) Paul [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26077. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26077 Checkstyle reports -Licenses incorrect --- Additional Comments From [EMAIL PROTECTED] 2004-01-13 00:36 --- What's the difference between this and doing maven jalopy:format? - 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: @author tags in Struts code
That means a lot coming from you Craig! I want to get some feedback on some other changes I'd like to suggest: on http://jakarta.apache.org/struts/volunteers.html (volunteer.xml) the current section order is: Source Code Contributers Documentation Contributers Active Committers Emeritus Committers how about reordering the sections to Active Committers Emeritus Committers Source Code Contributers Documentation Contributers I don't know if there's already some other convention on that, but developers are listed before contributers in project.xml, so it seems like a logical ordering. It also highlights those first who made very important contributions. I noticed that a couple of active committers were not listed in the source code contributers! That will be fixed when I update the list. This includes James Mitchell, Joe Germuska and David M. Karr.*** *I'm grabbing all the author tags under /src. Should the same be done under contrib as well? The scope of files involved in src is already several hundred, so If that's required I'll do that seperately as a seperate item. I think it would be good to mention the new policy on @author tags and that we're including people on the volunteer page in the documentation on how to help. Anyone have some good wording for that? Paul Sundling Craig R. McClanahan wrote: Quoting Paul Sundling [EMAIL PROTECTED]: If the group was interested in removing all author tags and consolidating all the names onto volunteer.html I would be willing to make a tar of patches or whatever format is most convenient. If you're interested, let me know if that would be useful and I'll try to give you 24 hour or less tournaround time. I'd probably have to ask for couple questions and then I'd submit it through bugzilla. It's in the realm of busy work, but I'm very detail oriented and pretty good with a CLI. :) +1 on such a patch, attached to a Bugzilla ticket in cvs diff -u format as David pointed out. Ironically, this would definitely count as enough work to get you added to the contributor list if you are not already :-). Paul Sundling Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
list of authors
I forgot to attach the list of author tags and their status for the curious. Paul Sundling * @author Anthony Kay [ADD] * @author Arron Bates [listed] * @author Cedric Dumoulin [listed] * @author Craig McClanahan [on list already as Craig McClanahan] * @author Craig R. McClanahan [listed] * @author David Geary [listed] * @author David Graham [listed] * @author David Wintefeldt [mispelled version] * @author David Winterfeldt [listed] * @author Dominique Plante [listed] * @author Don Brown [listed] * @author Don Clasen [listed] * @author Eddie Bush [ADD] * @author Erik Hatcher [ADD] * @author Florent Carpentier [listed] * @author James Mitchell [ADD] (listed only as Active Committer) * @author James Turner [listed] * @author Jea-noel Ribette [ADD] * @author Jeff Hutchinson [listed] * @author Jimmy Larsson [listed] * @author Joe Germuska [ADD] (listed only as Active Committer) * @author Leonardo Quijano [listed] * @author Luis Arias [EMAIL PROTECTED] [listed] * @author Marius Barduta [listed] * @author Martin Cooper [listed] * @author Martin F N Cooper [on list already as Martin Cooper] * @author Michael Westbay [ADD] * @author Mike Schachter [listed] * @author Niall Pemberton [EMAIL PROTECTED] * @author Oleg V Alexeev [ADD] * @author Paul Sundling [ADD] * @author Ralph Schaer [listed] * @author Robert Leland [on list already as Rob Leland] * @author Rob Leland [listed] * @author Scott Carlson [ADD] * @author Steve Raeburn [listed] * @author Ted Husted [listed] * @author a href=mailto:[EMAIL PROTECTED]Berin Loritsch/a [ADD] * @author a href=mailto:[EMAIL PROTECTED]Giacomo Pati/a [ADD] * @author a href=mailto:[EMAIL PROTECTED]Pierpaolo Fumagalli/a [ADD] * @author a href=mailto:[EMAIL PROTECTED]Stefano Mazzocchi/a [ADD] From Committers List Only: * David M. Karr (dmkarr at apache.org) [ADD] (listed only as Active Committer) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: begining with struts
Have you tried the struts user list? That's a more appropriate place to address a question like this. You emailed the developer list. Since the root cause is not finding a class you might start by making sure that you have the struts.jar and other dependent libraries somewhere that tomcat can find them. I've noticed that tomcat5 didn't seem to find stuff in my jre/lib/ext directory, like tomcat 4 did. So you need to have it in either $TOMCAT_HOME/common/lib or $TOMCAT_HOME/webapps/yourWebAppName/WEB-INF/lib. If you started with struts-blank.war file that will have the jars in the right place already. As far as tuturials and documentation, http://jakarta.apache.org/struts/faqs/index.html is a good place to start. Paul Sundling gabriel eduardo oliveros valencia wrote: hi i'm starting to program with java struts i'm following a struts tutorial than i downloaded from the web i'm doing a example hello world and it don't work the error than i get is the follow: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: No se puedee cargar la clase TagExtraInfo llamada: org.apache.struts.taglib.bean.CookieTei org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:404) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:319) org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:453) org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:290) org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:204) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:458) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:523) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1577) org.apache.jasper.compiler.Parser.parse(Parser.java:171) org.apache.jasper.compiler.ParserController.parse(ParserController.java:247) org.apache.jasper.compiler.ParserController.parse(ParserController.java:149) org.apache.jasper.compiler.ParserController.parse(ParserController.java:135) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:237) org.apache.jasper.compiler.Compiler.compile(Compiler.java:456) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:552) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:291) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) root cause java.lang.ClassNotFoundException: org.apache.struts.taglib.bean.CookieTei org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1366) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1213) org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:450) org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:290) org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:204) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:458) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:523) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1577) org.apache.jasper.compiler.Parser.parse(Parser.java:171) org.apache.jasper.compiler.ParserController.parse(ParserController.java:247) org.apache.jasper.compiler.ParserController.parse(ParserController.java:149) org.apache.jasper.compiler.ParserController.parse(ParserController.java:135) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:237) org.apache.jasper.compiler.Compiler.compile(Compiler.java:456) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:552) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:291) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) somebody have a struts tutorial than help me to learn about java struts? i have jakarta-tomcat-5.0.16 and j2sdk1.4.1_06 thx for your colaborations Gabriel Oliveros _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: DO NOT REPLY [Bug 26036] - Remove author tag and consolidate under volunteer.html
That's probably just as well. Otherwise everyone would get like 385 commit messages.Glad to hear it went OK. Paul Sundling David Graham wrote: I got an error email response from the apache mail server because the commit message was so large so I don't think struts-dev will receive notification. The patch and commit worked flawlessly though. David --- [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036 Remove author tag and consolidate under volunteer.html [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 21:05 --- Fixed...thanks for the patch! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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: maven checkstyle report
Actually, I was realizing that Option 2 is only a quick fix, not a solution and that eventually there will still be a bunch of tab errors. Realizing that we'll be accepting code from people who may or may not be using tabs, it's likely to be a persistant error... Some assistance could be provided by an ant target like this that I used to package my own code for a client who hated tabs: target name=notabs description=Replace tab with 4 spaces replaceregexp match=\t replace= flags=g fileset dir=web excludes=**/images/* / /replaceregexp /target Even that assumes a tab is always the same number of spaces, which is the whole issue with tabs in the first place. I personally like tabs, but not as much as I like consistency. :) Paul Joe Germuska wrote: 2. Tab errors: It has an error for tabs in the files. Option 1 we remove the tabs check from checkStyle. Option 2 we replace tabs with spaces and do a quick visual check to see how everything lines up. Which approach to take here isn't as obvious. How important is it wether there are tabs or spaces? That's not really my call, but I'm willing to take care of it either way. This is the stuff religious wars are made of; it is true, though, things like diff work much better if indentation is done consistently, whichever character is used. I don't recall if there's an official preference in Struts, but I imagine someone will pipe in if it's important to them. If it turns into a big debate, better to disable the tabs check, because as you say, it'll improve the signal-to-noise ratio in the checkstyle reports. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags in Struts code
If the group was interested in removing all author tags and consolidating all the names onto volunteer.html I would be willing to make a tar of patches or whatever format is most convenient. If you're interested, let me know if that would be useful and I'll try to give you 24 hour or less tournaround time. I'd probably have to ask for couple questions and then I'd submit it through bugzilla. It's in the realm of busy work, but I'm very detail oriented and pretty good with a CLI. :) Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: http://jakarta.apache.org/struts/userGuide/index.html has a list of contributors on the side. http://jakarta.apache.org/struts/userGuide/release-notes.html has a much smaller list of contributers. Those are just the people who contributed to that page on the site. The title Contributors is misleading. We should probably remove those names if we remove the @autor tags. Then of course, there's authors in individual javadocs. I probably wouldn't have added my author tag if there wren't already several already in the file. If you remove the author tags, maybe you could add those to that main contributer page. That would take care of people like me who have an author tag, but aren't listed. That's what I was thinking as well. At least so far, I probably don't deserve a listing with only two very minor patches and one implemented suggestion, but it would still be nice. :) Hopefully, I'll be able to contribute more meaningfully in the near future. Every person that provides a patch that's committed to the Struts code or docs deserves to be listed. Every contribution, no matter how small, is greatly appreciated! I've attached a list of all author tags in all their 41 permutations (other than spaces) in case you wanted to do that and remove the author tags. There's about 468 author tags instances if you plan on removing them. Thanks for the list. It will certainly help identify people missing from the contributors page. Even better would be to create a patch for the volunteers page that adds the missing people :-). Paul Sundling PS you can share this with the list if you think any of this info is helpful. In the future you should send comments like this directly to struts-dev so more people can comment and volunteer for changes. David David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: Now you've got me curious. Which specific page you mean, since I've noticed various pages with different contributor lists? What sort of criteria are used to figure out if someone deserves a listing? I'm referring to this one: http://jakarta.apache.org/struts/volunteers.html What are the others you've seen? If there are duplicates, we should probably combine them into one page. Providing a patch for code or docs qualify someone to be listed on the site. David - * @author Berin Loritsch* @author Giacomo Pati* @author Pierpaolo Fumagalli* @author Stefano Mazzocchi* @author Anthony Kay* @author Arron Bates* @author Cedric Dumoulin* @author Craig McClanahan* @author Craig R. McClanahan* @author David Geary* @author David Graham* @author David Wintefeldt* @author David Winterfeldt [probably the correct one]* @author Dominique Plante* @author Don Brown* @author Don Clasen* @author Eddie Bush* @author Erik Hatcher* @author Florent Carpentier* @author James Mitchell* @author James Turner* @author Jea-noel Ribette* @author Jeff Hutchinson* @author Jimmy Larsson* @author Joe Germuska* @author Leonardo Quijano* @author Luis Arias * @author Marius Barduta* @author Martin Cooper* @author Martin F N Cooper* @author Michael Westbay* @author Mike Schachter* @author Niall Pemberton * @author Oleg V Alexeev* @author Paul Sundling* @author Ralph Schaer* @author Robert Leland* @author Rob Leland* @author Scott Carlson* @author Steve Raeburn* @author Ted Husted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Reports
I was looking at the maven reports and they're pretty interesting. One
thing I found interesting was the report that shows duplications. There
is a large number of classes that only differ in which class they
extend. One large grouping of that is in the nested taglib classes. In
the example below you'll see that the only differences are the import
line and extends clause. It seems there should be some design pattern
to where all the duplicate code could be refactored into one location.
Of course, I couldn't think of one right away myself. Would the IoC
stuff that's been mentioned help here for instance?
Paul Sundling
EXAMPLE DIFF FOLLOWS
[EMAIL PROTECTED] logic]$ pwd
/home/tkz/workspace/jakarta-struts/src/share/org/apache/struts/taglib/nested/logic
[EMAIL PROTECTED] logic]$ diff NestedMessagesPresentTag.java
NestedNotEqualTag.java
2,4c2,4
* $Header:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/NestedMessagesPresentTag.java,v
1.5 2004/01/01 20:00:33 husted Exp $
* $Revision: 1.5 $
* $Date: 2004/01/01 20:00:33 $
---
* $Header:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/NestedNotEqualTag.java,v
1.4 2003/02/28 05:14:39 arron Exp $
* $Revision: 1.4 $
* $Date: 2003/02/28 05:14:39 $
65,66c65,66
import org.apache.struts.taglib.logic.MessagesPresentTag;
import org.apache.struts.taglib.nested.NestedPropertySupport;
---
import org.apache.struts.taglib.logic.NotEqualTag;
import org.apache.struts.taglib.nested.NestedNameSupport;
70c70
* NestedMessagesPresentTag.
---
* NestedNotEqualTag.
73d72
* @author David Winterfeldt
75c74
* @version $Revision: 1.5 $ $Date: 2004/01/01 20:00:33 $
---
* @version $Revision: 1.4 $ $Date: 2003/02/28 05:14:39 $
77,78c76
public class NestedMessagesPresentTag extends MessagesPresentTag
implements
NestedPropertySupport {
---
public class NestedNotEqualTag extends NotEqualTag implements
NestedNameSupport {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started building struts from source - need a little help
If you look at some of my earlier messages you'll see I encountered the problem as well. You notice that Joe Germuska was even kind enough to add a comment to the project.xml as I suggested. So you can go and get the jar for the new validator from the URL in the comment below and then put it in your maven repository. For further information, here's the comment from the project.xml: !-- Note that this version of commons-validator is not yet served from the iBiblio repository. You can download a distribution from http://www.apache.org/~rleland/ValidatorAlpha/1.1.1/or build it from the CVS repository. (With Maven, you can use the goal jar:install to build a jar and put it in your Maven repository.) If you download the binary, don't forget to rename to include the version number (from commons-validator.jar to commons-validator-1.1.1.jar If you build it from the CVS repository, you will probably end up with version 1.1.2-dev. You can tell Maven to use that version with Struts by editing your build.properties file in the root of your local copy of the Struts CVS distribution. Include these two lines: maven.jar.override=on maven.jar.commons-validator=1.1.2-dev Paul Sundling Daniel Rabe wrote: - I also tried building from maven (thought it would save me the hassle of finding all the jars and editing build.properties). It fails, unable to find commons-validator-1.1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags in Struts code
I can see a lot of valid points in the article. I also don't buy the positive side regarding author tags helping point out who to go to for help on a particular file. Whatever the final decision, the philosophy should be documented on the web site in the section where it talks about how to help. There are however two reasons why I think such artifacts as author tags are good (although I think CVS comments are better if consistent). 1. For non-committers, it gives us warm fuzzies. It's like a little flag that says I actually made my contribution to open source, like more of us out there should. You can't go in CVS and see that people like me added a patch, unless a committer actually takes time to actually mention it without an author tag. If there were some template text, like Based on a patch contributed to ASF by [EMAIL PROTECTED] related to bugzilla # . in the CVS log I think that would be good enough. Even though I've had a VERY VERY minor contribution, it was quite a rush to have an author tag on a minor support file. It made me feel like a part of the project and it made me want to get more involved. [I'm getting into unit testing, so I figure I might make contributions there first down the line.] I would never want to cause any resentment against those doing the brunt of the work or claim that I'm on the same level. At the same time, it's nice to have a little reminder somewhere that I'm making a contribution, however small. 2. There should be some tracking for the origins of code in case we ever get attacked by a company like SCO. Maybe there's already some cross referencing system that I'm not aware of between bugzilla and CVS that already takes care of this. I guess this is counter to legal protection under the ASF umbrella. Let's say I work at Top Secret Corp or Run By Lawyers Inc. and I submit a patch that my employer would see as infringing code. It's good code and one of committers (David Graham for instance, since I'm replying to his message) commits it into CVS. It now looks like David was the source for the code and when Top Secret Corp lawyers started sniffing around it'd be harder to find out the true source. I would guess this might end up being a major issue depending on how the SCO law suit ends. Paul Sundling David Graham wrote: The @author javadoc tag topic has been discussed on commons-dev recently and Ted brought it up in a recent struts-dev thread so I thought it might be nice to get the Struts community's opinion on it. Some arguments against @author tags by Greg Stein can be found here: http://tinyurl.com/yrlhu I'm not too concerned about the legal issues because I don't think there are any. I think it's a good idea to remove all of the tags rather than each person removing their own so that the remaining tags don't misrepresent who did most of the work (kind of an all or nothing deal). Comments? David __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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: design - tags with errors
It's my bad. It looks like there is not a problem with the options tags. The real problem is that I included a jsp in the page where I was getting the exception. So in simplist terms: jsp:include page=/includes/largeEnough.jsp/ bean:message key=key.that.causes exception.because.it.does.not.exist/ following html and bunch of stuff... So when I get a blank page, I just have to comment out the include to see the errors. Sorry for the false alarm. Paul After rereading it again I think I should clarify one of my comments: Even generating nothing would seem to be prefereable! What I meant by that is the tag itself generating nothing (resulting in an empty select list) as opposed to the entire page generating nothing(current behavior). That would be very much appreciated. You can file a Bugzilla report with your patches attachment. I was wondering what the general design philosophy for errors inside custom tags is. I've noticed that when there's a problem with html:option*, instead of giving a useful error message, it would just fail to display anything (clean white page).Is that the desired result? I'd be willing to modify the class to use error messages instead of crashing the page, if I'm not the only one who finds that desirable. Even generating nothing would seem to be prefereable! (Pointing me to a tag with the kind of preferred error handling that I should emulate would be useful.) Paul Sundling - 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]
design - tags with errors
I was wondering what the general design philosophy for errors inside custom tags is. I've noticed that when there's a problem with html:option*, instead of giving a useful error message, it would just fail to display anything (clean white page).Is that the desired result? I'd be willing to modify the class to use error messages instead of crashing the page, if I'm not the only one who finds that desirable. Even generating nothing would seem to be prefereable! (Pointing me to a tag with the kind of preferred error handling that I should emulate would be useful.) Paul Sundling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: design - tags with errors
After rereading it again I think I should clarify one of my comments: Even generating nothing would seem to be prefereable! What I meant by that is the tag itself generating nothing (resulting in an empty select list) as opposed to the entire page generating nothing(current behavior). I was wondering what the general design philosophy for errors inside custom tags is. I've noticed that when there's a problem with html:option*, instead of giving a useful error message, it would just fail to display anything (clean white page).Is that the desired result? I'd be willing to modify the class to use error messages instead of crashing the page, if I'm not the only one who finds that desirable. Even generating nothing would seem to be prefereable! (Pointing me to a tag with the kind of preferred error handling that I should emulate would be useful.) Paul Sundling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch to add sorting enhancements org.apache.struts.util.LabelValueBean
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
I have attached the complete file beside including the diff in case that
is useful.
The diff versus version 1.6 of the file (
# diff LabelValueBean.java.version1.6 LabelValueBean.java
65c65
---
import java.util.Comparator;
74a75,76
* @author Paul Sundling
*
77c79
public class LabelValueBean implements Serializable {
---
public class LabelValueBean implements Comparable, Serializable {
181a184,210
/**
* 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);
}
};
/*
* $Header:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java,v
1.6 2003/07/04 18:26:19 dgraham Exp $
* $Revision: 1.6 $
* $Date: 2003/07/04 18:26:19 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Struts, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE
