Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
-Original Message- Do we want to wait for a Validator 1.1.2, or roll it with 1.1.1? I just fixed a show stopper bug today in validator in CVS and made an accompaning change in Struts CVS. I won't be able to be RM to for Validator until Mid April, so we need a volunteer. Otherwise, we'll need to roll back the JavaScriptTag.java and validator-rules.xml in struts to use validator 1.1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL validation - anyone using it?
From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Broken interface: forwardURL(HttpServletRequest, ForwardConfig)
That was definatly a mistake. It was made between version 1.145 1.146 of the file (Which was the very last CVS commit) back on 2/13/2004 related to bug #24235 in a number of patches right before 1.2.0 was released. -Original Message- From: Marino A. Jonsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 06:52 PM To: [EMAIL PROTECTED] Subject: Broken interface: forwardURL(HttpServletRequest, ForwardConfig) Hi guys, I am a Apache Velocity-Tools developer and I just noticed you have removed the forwardURL(HttpServletRequest, ForwardConfig) method, that was introduced in Struts 1.1, from RequestUtils in favour of forwardURL(HttpServletRequest, ForwardConfig, ModuleConfig). Any reason not to deprecate first, before removing altogether? cheers, Marino - 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: Broken interface: forwardURL(HttpServletRequest, ForwardConfig)
A Compatable method was just and will be in the nightly build for March 12th. -Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] That was definatly a mistake. It was made between version 1.145 1.146 of the file (Which was the very last CVS commit) back on 2/13/2004 related to bug #24235 in a number of patches right before 1.2.0 was released. -Original Message- From: Marino A. Jonsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 06:52 PM To: [EMAIL PROTECTED] Subject: Broken interface: forwardURL(HttpServletRequest, ForwardConfig) Hi guys, I am a Apache Velocity-Tools developer and I just noticed you have removed the forwardURL(HttpServletRequest, ForwardConfig) method, that was introduced in Struts 1.1, from RequestUtils in favour of forwardURL(HttpServletRequest, ForwardConfig, ModuleConfig). Any reason not to deprecate first, before removing altogether? cheers, Marino - 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: [RESULT][VOTE] Struts as an Apache Top Level Project
Since Craig indicated his preference NOT to be VP, how does this impact this proposal ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts nightly build now needs Validator-1.1.2-dev
I just made a change in validator that allows multiple forms per page. In order for client side validation to work Struts needs to be build with the nightly version of Validator. At one time this was true, but then a few weeks ago there was talk about building it against the released version 1.1.1. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASL 2.0
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]
Re: [VOTE] Struts as an Apache Top Level Project
+1 for Struts TLP +1 for Craig as VP -Original Message- For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TranZ NetworkZ - Received Your Mail
Dear Customer, We Will Get Back To You Shortly. Regards, Suresh (91) 080-23561956 (91) 044-24838112 Bangalore - India - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TranZ NetworkZ - Received Your Mail
Dear Customer, We Will Get Back To You Shortly. Regards, Suresh (91) 080-23561956 (91) 044-24838112 Bangalore - India - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Build (Re: Struts Change Tracking)
-Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Thank you. The current build does generate the Mavenized web site when you run Just a reminder: the xdocs directory should not be maintained - the live I synced the xdocs to docs about a month ago using a comparison tool, though I realized that 'doc' is the master. Because of that I wouldn't want it deleted, since getting the docs in there is half the work. test files in their place for continued Maven build testing. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TranZ NetworkZ - Received Your Mail
Dear Customer, We Will Get Back To You Shortly. Regards, Suresh (91) 080-23561956 (91) 044-24838112 Bangalore - India - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Build (Re: Struts Change Tracking)
-Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] I think I committed anything I had a while ago. So the demo website that you posted should be able to generated using the current build ? Also you mentioned that you had a script to automatically move over the docs to xdocs. If so could that also be Checked in ? And of course Congradulations on your new Job ! If Tim, or anyone else, want to submit patches, I'll gladly look them over and check them in but, in the short term, I probably won't be doing much myself since I've just started a new job. Once that settles down, I'll get back to it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: February 27, 2004 5:36 PM To: Struts Developers List Subject: Re: Maven Build (Re: Struts Change Tracking) It was Steve R. that said he would committ changes after 1.2.0. -Original Message- From: Tim Chen [mailto:[EMAIL PROTECTED] I can help with the maven build. I had some patches for the maven build way back when that were incorporated and have learned quite a bit more about maven since then. I haven't had time to work on anything else for struts lately but I have a bit more time now. But I don't want to step on anyone's toes. If you have something in particular that you would like to to do please let me know. :) -Tim Joe Germuska wrote: At 4:48 PM + 2/27/04, Robert Leland wrote: -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Even though Maven isn't our primary build mechanism, Joe, It's been a while but was it you or someone else that had a bunch of Maven build changes to check in after 1.2.0 went out the door ? Wasn't me; I did update project.xml to version 1.2.1-dev and added the 1.2.0 version/tag to the versions element. I haven't got anything specific pending. I'd like to work on getting the Cactus tests running again, although I'll need some other eyes on it, and I would love for maven to be able to build the site -- I'm not going to have a ton of time for any of this in the next few weeks, though. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Build (Re: Struts Change Tracking)
It was Steve R. that said he would committ changes after 1.2.0. -Original Message- From: Tim Chen [mailto:[EMAIL PROTECTED] I can help with the maven build. I had some patches for the maven build way back when that were incorporated and have learned quite a bit more about maven since then. I haven't had time to work on anything else for struts lately but I have a bit more time now. But I don't want to step on anyone's toes. If you have something in particular that you would like to to do please let me know. :) -Tim Joe Germuska wrote: At 4:48 PM + 2/27/04, Robert Leland wrote: -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Even though Maven isn't our primary build mechanism, Joe, It's been a while but was it you or someone else that had a bunch of Maven build changes to check in after 1.2.0 went out the door ? Wasn't me; I did update project.xml to version 1.2.1-dev and added the 1.2.0 version/tag to the versions element. I haven't got anything specific pending. I'd like to work on getting the Cactus tests running again, although I'll need some other eyes on it, and I would love for maven to be able to build the site -- I'm not going to have a ton of time for any of this in the next few weeks, though. Joe - 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: DO NOT REPLY [Bug 27235] - html:text onchange= . . ./
It's on a project by project basis, and asking as your doing now is the best way to know. I usually respect the wishes of the committers that are currently doing the heavy lifting, and that changes over time. Currently, some are for and some against. A while back a user was trying to be helpful and marked literally a 100 bugs as invalid. Besides the flood of emails, I and others got annoyed and had to reopen many of them, since many were valid bugs. The end result was positive in that it woke us up and made us review the bug tickets, but that wasn't a way to make friends :-) ! Comments such as you made are helpful, since few of us are experts on everything, and we welcome advice and input. -Rob -Original Message- From: Richard Bywater [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 12:43 AM To: 'Struts Developers List' Subject: Re: DO NOT REPLY [Bug 27235] - html:text onchange= . . ./ Hi, Regarding the comment I made for the bug below, is there any authority required to set a bug as invalid or is it open for anyone to do so (with a good reason of course :) ) Just wondering for the future... Thanks, Richard. [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=27235. 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=27235 html:text onchange= . . ./ --- Additional Comments From [EMAIL PROTECTED] 2004-02-25 20:52 --- The HTML spec actually says that it should be onchange (all script events are lowercase) therefore Struts is doing the right thing. On a side note they both work on Firefox (which is based on Mozilla 1.6 so maybe the bug is actually with Mozilla 1.5?) I'm not sure if I'm allowed to resolve this bug as invalid so I'll leave that to someone else to do :) (Am I allowed to as a pleb?) - 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: Bug in JavascriptValidatorTag
Once a release is tagged that's it. We could retag and do 1.2.1,
however there will probably be other things that need to be fixed.
The point is to get 1.2.0 out the door and then see about making
whatever fixes that need to happen.
Do we have or want to make a 1.2 branch ?
-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 02:03 PM
To: 'Struts Developers List'
Subject: Re: Bug in JavascriptValidatorTag
Hm. No one brought that up when we were talking about implementing
the fix, but that explains the old default behavior, which was to
render the javascript without wrapping script tags. That makes sense
when you're rending javascript for external use.
It seems to me that the solution would be fixed by moving the check
for a non-null form into createDynamicJavascript, where there is
nothing to be done if the form is null.
Does this get fixed in 1.2.1? Or do we fix it now and move the
release tag for that file?
Obviously I don't use static javascript, or I would have seen the
problem with the fix before -- would anyone care to double check my
logic here?
Joe
At 6:29 AM +0100 2/24/04, Ralph Schaer wrote:
I've found a bug in JavascriptValidatorTag.java.
(Nightly build 2004/02/23)
I use this tag in one of my jsp pages:
html:javascript dynamicJavascript=false staticJavascript=true/
Now the JavascriptValidatorTag crashes with this error message:
javax.servlet.jsp.JspException: No form found under name null, locale de_CH
The error occurs on line 381. There is a null check for the form
attribute. But there is no need for a form when you just want the
static part of the validator javascript code.
if (form == null)
{
throw new JspException(No form found under name
+ formName
+ , locale
+ locale);
}
--
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]
Re: 1.2.0 is tagged and frozen
Here is what I understood (and used with Validator) Action Response Step #0) Vote for release process to start. RM begins grueling work. Step #1) A release is made. An announcement made on DEVSavvy users download, test. #2) After a period of time A VOTE is held. Release withdrawn. Release promoted to LA Release promoted to GA. #3) Step #2 repeated for same release. LA = Announced on Apache only, STRUTS-DEV, STRUTS-USER GA = Announce inside/outside Apache STRUTS-DEV/STRUTS-USER/Slashdot/Theserverside/freshmeat. At any time Step #2 may be repeated for the same release. So it can be promoted from LA to GA, GA to LA, or Withdrawn. Note that there is no confusing Release Canidates, all releases are releases. Step #0 is required becasue we are part of Jakarta Step #1, #2, #3 is what httpd uses. (I had typed this up earlier but my email timed out, gurr!) -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 05:42 PM To: 'Struts Developers List' Subject: Re: 1.2.0 is tagged and frozen On Mon, 23 Feb 2004, Ted Husted wrote: On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? Following Craig's description of the Tomcat release approach (copy below), I'd say we should make an announcement to the Struts DEV and USER lists, with an URL leading to one of our home directories (or wherever Tomcat and others have been posting such things), but not the Jakarta announcement list. I imagine we'd now reserve the latter for a General Availability release that's being mirrored. I'm fine with restricting the announcement as you describe. However, given the size of the struts-user list in particular, I'm not so sure about not taking advantage of mirroring for downloads. I'll take a look at what the Tomcat folks are doing in this regard, though, and just do what they do. ;-) Sorry if the taglib-exercise module is flaky. If it is, mea culpa. But once it's up there, we can still announce it, see if there is anything else we can fix, and then try again with 1.2.1. That would also give us a chance to apply that license patch. No biggie. As I said, I'm not overly concerned by the failures I saw, although I do want to verify that the problems with (2c) are also test app problems and not actual bugs in the core. I'll try to check that tonight, but I'd be happy if someone else beat me to it. ;-) Once I get the build uploaded (grr!), I'd like someone to try out the Cactus tests and make sure that most of them, at least, run OK before I send out an announcement. 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 -Ted. On Tue, 16 Dec 2003 11:27:45 -0800, Craig R. McClanahan wrote: The Tomcat folks do indeed vote on every release -- they just do things in a little different order: * Post what amounts to a release candidate and announce to a limited audience (dev and user lists) asking for testing. * Testing ensues ... * Call a vote on the release, with the options to call it alpha, beta, stable (that's fine with me), or withdraw (if there was some bad problem). * Announce to the world and do the usual process of distributing the bits. The same approach would work for us, and IMHO meets the Jakarta requirements with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on releases as well, to be consistent with the current ASF reqirements. On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts- examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release
Re: [VOTE] 1.2.0 Release Plan
-Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 12:46 AM To: 'Struts Developers List' Subject: RE: [VOTE] 1.2.0 Release Plan 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. The committers project in CVS has python java versions that does this automatically. The Python version has undergone several versions to improve the copyright conversion. You might want to start there first. -ROb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Be sure to put the CVS TAGS in the refernce license.txt so it will add them automatically, at least the python version was ok with that. -Rob -Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 11:27 PM To: 'Struts Developers List' Subject: 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
Re: Status of struts-examples
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] If there aren't any strong objections, then, I'd like to remove them and make a clean break with the things we did for the sake of the 1.1 march. +1 sounds good ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: userguide logic:lessEqual error
Fixed, Thanks! -Original Message- From: Matt Bathje Not sure if I should put in a bug report for this or what - but there is a typo on: http://jakarta.apache.org/struts/userGuide/struts-logic.html it says for lessEqual: Evaluate the nested body content of this tag if the requested variable is greater than or equal to the specified value. and it says for greaterEqual: Evaluate the nested body content of this tag if the requested variable is greater than or equal to the specified value. Not too huge, but thought I'd point it out. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of struts-examples
It would be nice(-0) to keep these around for a while longer, unless we are worried about bandwidth and want to encourage users to use the docs in the distro. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 01:24 AM To: 'Struts Developers List' Subject: Re: Status of struts-examples One other thing are the JavaDocs under legacy. We started doing this during the Stuts 1.0 / 1.1 march when there was a serious gap between the shipping version and development version. These have been unlinked from the website for some time now, and I think they can be removed. I'd like to go ahead and do this before the 1.2.0 release. -Ted. - 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]
html:text disable attribute invalid.
http://www.w3.org/TR/html4/interact/forms.html#h-17.4 Looking at the above reference it appears that the disable attribute is illegal for type=text, is this correct ? If so should we remove this attribute, as opposed to deprecating it ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:text disable attribute invalid.
After looking at the DTD again I see I was mistakend when it said not available in this context, ie disabled, I was thinking the attribute instead of the control. -Rob -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] I must be missing something. What in that link indicates disabled is not valid for a text input? David [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://www.w3.org/TR/html4/interact/forms.html#h-17.4 Looking at the above reference it appears that the disable attribute is illegal for type=text, is this correct ? If so should we remove this attribute, as opposed to deprecating it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26942] - Parse error using set-property for forward in struts-cfg.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] We should remove the type and other deprecated attributes from the DTD before releasing 1.2.0. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser-specific attrs for html tags (was: [Bug 26795])
-Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] I've always been sympathetic to the goal of enforcing the HTML standard, particularly for internet applications, as opposed to intranet applications. However, when it comes to supporting intranet applications, a more effective approach might be the pragmatic one. I always felt there should be a html-ex tag library at the sourcefourge struts site. It would be argument compatable with the struts html except that it would offer the additional attributes needed. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deprecate org.apache.struts.taglib.html.ErrorsTag?
Is there any reason not to deprecate org.apache.struts.taglib.html.ErrorsTag and slate it for future removal, to remove one more piece from the puzzle? Joe +1 Once Message Resources is out of the sandbox I believe we can complete the moving over to Messages, by changing method signatures from to ActionMessages as opposed to ActionErrors. We'll need to create new methhods of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Summary: Clean Up conf/share
Ok based on feedback: validation_1_1.dtd validator-rules_1_1.dtd tiles.tld will be removed. I am not sure where we are with not supporting the struts 1.0 dtd since we don't support data sources. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clean Up conf/share
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 4, 2004 04:24 AM To: 'Struts Developers List' Subject: Re: Clean Up conf/share On Wed, 4 Feb 2004, [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 Yes, they should, but we still support config files with the 1.0 format. Are you suggesting we remove that support? I'm not so sure I'd agree with that, as it forces everyone to convert their config files, which may well be quite an onerous task for a large application that otherwise has no reason to change (but which wants to pick up bug fixes in later versions Yes there is. Unless we can support all the features the DTD specifies then I would say remove it. Since Struts 1.2 does not support datasources any more both the 1.0 and 1.1 DTD should be disallowed. 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 Same comment as for the Struts config files, above. I can't make the same argument as above, however both Struts 1.1 and 1.2 do not read the Validator XML it is commons-validator that reads the files. Having Struts register the DTD with the digester when it doesn't read in the XML is suspect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:javascript behavior when form is not found
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] 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... I am all for in-your-face. Tapestry has sort of a built in debugging web page that gives all sorts of stats, on your running web app. The least we can do is Blow up in a loud usefull way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clean Up conf/share
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 -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecated: ActionError
-Original Message- From: Matthias Wessendorf Hi, So i looked at our validate() in ActionForm, but there is still ActionErrors. So i wondered, why the validator uses Messages and the validate() uses Erros... Good Question: We talked about this a few months ago on the struts-dev list. I believe since we can't have both ActionMessages validate() ActionErrors validate() Some developers wanted to wait for Struts 2.0 to deprecate the method. Some wanted to do it sooner. There really isn't a reason why we couldn't add a doValidate() method that returned a ActionMessages. and also i saw, that the validator gets initialized with an ActionErrors-object in: Resources.initValidator(); inside of initValidator() this happends: validator.setParameter(ACTION_ERRORS_PARAM, errors) but key for errors is this: private static String ACTION_ERRORS_PARAM = org.apache.struts.action.ActionMessages; the first parameter of setParameter() is called: parameterClassName. so the errors gets initialized as an ActionMessages-object, isn´t? so question: why is the ActionErrors not deprecated? in release-notes i saw: Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. why not in all? it would be fine, to know this ;-) greetings Matthias Matthias Weßendorf Email: mailto:[EMAIL PROTECTED] URL: http://www.wessendorf.net - 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: Running Struts Cactus tests with Ant
-Original Message-
From: tomcatlist user [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 6, 2004 04:20 PM
To: 'Struts Developers List'
Subject: Re: Running Struts Cactus tests with Ant
When I invoke maven, it complains about not finding commons-validator
version 1.1.1-dev, so I tried modifying that to use the last version
instead (1.0.2). It's a good thing I remembered someone mentioning
commons-validator and the maven build. Looking through my messages I
found this:
1.0.2 will work with the nightly build, only if you use the
validator-rules.xml from struts 1.1. There are been a number of improvements
in the javascript validation. The 1.1.1 download is still available under
my home directory. Let me know if there are any problems.
-Rob
I've updated project.xml to reference the validator 1.1.1 jar. You need
to manually download it from http://www.apache.org/~rleland/ and place
it in your local repository.
If this is going to persist, maybe it might be worth a common in the
project.xml? If I wasn't paying attention to the list, I wouldn't
necessarily know where to get the updated version. :)
I got a lot of deprecation errors, but otherwise, both the default
jar:jar and dist goals finished! So with minor caveats, even a maven
novice can build struts. That's great considering.
Paul Sundling
Tim Chen wrote:
Sorry.. The default target is currently set up as jar:jar
That will do everything that you need it to.
So all you have to do is:
//step-by-step-build-struts-with-maven.readme
1) Download maven 1.0 rc1 from http://maven.apache.org
2) Add a maven_home env variable that points to where you installed
maven to
3) Add ${maven_home}/bin or %MAVEN_HOME%\bin to your path
4) Optional: set
MAVEN_OPTS=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.pro
cessor.TransformerFactoryImpl
This is not really necessary as I set the path for the xalan
TransformerFactory in the maven scripts but could save you the hassle
with other projects that might require xalan.
5) checkout jakarta-struts.
NOTE: At this point you do not need to have anything in your classpath.
6) cd to jakarta-struts root
7) invoke either:
- maven
by default runs jar:jar which will simply jar up
struts-1.2.0.jar into your maven build directory (currently set to
${jakarta-struts_home}/m-target)
- maven dist
this task will create not just the jar but also create a
${jakarta-struts_home}/m-target/distributions
Directory that has zip and tar.gz versions of the bin and src
distributions
I have been really busy the last few weeks and haven't had a chance to
help Joe or to complete the distributions. So it will not include all
the items from the current ant build but at least you don't have to
manually set anything in jakarta-struts anymore :)
Tim Chen
[EMAIL PROTECTED]
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 16, 2003 6:52 PM
To: Struts Developers List
Subject: Re: Running Struts Cactus tests with Ant
--- James Mitchell [EMAIL PROTECTED] wrote:
Any chance someone wants to throw together a
step-by-step-build-struts-with-maven.readme?
cd your-struts-dir
maven build
Anything much more complicated than that defeats the purpose of using
Maven.
David
-
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: Struts EL Distro
I agree, also each of the *.war files have a copy of the .jar files. Would it be acceptable to have a script or ant to gut the WEB-INF/lib directory of war files before distribution then reinsert them by running another script after they are unpacked by the user? The Distro would be less than 4MB if we did that. We could create another ant target that never assembles the war files in the first place, and another 'ant demo-war' command could package the already compiled *.class files of the app into a war. -Rob -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 09:54 PM To: [EMAIL PROTECTED] Subject: Struts EL Distro The binary Struts build includes struts-el in the contrib directory. Why does struts-el/lib include the commons-*.jars and JSTL jars? The common jars are already distributed with the standard Struts build and the JSTL jars should be downloaded separately. Considering the frequency of Struts downloads and our large 21MB distro size, removing these duplicate jars will save Apache a considerable amount of bandwidth. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
- Also, again totally agreeing with Ted, make everything interface based, a few more hears here ;^) Joe Germuska The interface discussion has come up previously and there was some emotion tied to it. I was around for Interface ActionForms in pre Struts 0.5 and it was really ugly, what some developers tried to do. This then triggered a number of email's on the list to help them get it working. In almost all cases they were trying to break the MVC Model, and pile all the logic into the ActionForm implementation class they possibly could. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Discussion Forum
I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.
The advantages are we would most likely always have
a working framework, which would encourage user
participation, usage, testing. That means we could use it
in our paying jobs. Some of us may even be able to
justify working on Struts 2.0 on our paying Jobs time.
I am concerned where all the energy, time, code,
documentation, and testing will come from with a clean start.
I strongly believe one of the reasons Struts is so popular
is that we were big on compatibility between releases,
and so staying up to date with the latest Struts release or
nightly was not very painful.
The disadvantages are that it might seem like we
would have to do extra work in gradually refactoring
Struts into the next version.
Any code base that starts from scratch has to undergo
the painful process of setting up the initial classes,
tests etc... Again user participation, in usage, testing,
and contributions played a major, no, critical role in
struts's development, and we'll need that same input again.
However, now days there are many other frameworks with which to
choose.
Bottom line is I believe like you do that we are smarter now and
know better ways to do things. Look up Erick Hatchers comments
he made a few months ago on Struts, and ways to improve it as
an example.
-Rob
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 09:22 PM
To: 'Struts Developers List'
Subject: Re: Struts 2.0 Discussion Forum
Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the
discussion.
Don
There's a Whiteboard page in the Wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
I'll be posting more about Jericho, but wanted to get what I had so far
(a starter DTD) under CVS.
One other idea that I've been meaning to bring up in the wake of
wildcard Mappings, is the idea of merging context attributes into
ActionForward paths. For example, we could do something like
forward name=lookup merge=true path=/lookup.do?key={key} /
and have it replace {key} with request.getAttribute(key) (or session
if not found).
-Ted.
-
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
+1 -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 05:48 PM To: 'Struts Developers List' Subject: [VOTE] 1.2.0 Release Plan I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -Ted. - 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]
[Validator] was Re: [VOTE] 1.2.0 Release Plan
Ok, then with 'tomcat' reading of the rules, I can put the 1.1.1 back for limited testing and then say next week call for a vote on commons-validator to classify it. I confused the issue by calling it an Alpha instead of a RC. -Rob -Original Message- From: Craig R. McClanahan Quoting Martin Cooper [EMAIL PROTECTED]: The issue isn't so much with voting on the relesae plan, but voting on the release itself. As you say, the HTTPD rules say that anyone can create a release. We're not HTTPD, though, and the Jakarta rules are different. As long as we're part of Jakarta, we need to abide by the Jakarta rules. Under Decision Making, in the section on Release Testing, is the following statement: Majority approval is required before the release can be made. http://jakarta.apache.org/site/decisions.html So, we do need to vote on each and every release. The Tomcat folks do indeed vote on every release -- they just do things in a little different order: * Post what amounts to a release candidate and announce to a limited audience (dev and user lists) asking for testing. * Testing ensues ... * Call a vote on the release, with the options to call it alpha, beta, stable (that's fine with me), or withdraw (if there was some bad problem). * Announce to the world and do the usual process of distributing the bits. The same approach would work for us, and IMHO meets the Jakarta requirements with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on releases as well, to be consistent with the current ASF reqirements. +1 on the 1.2.0 release plan, by the way. -- Martin Cooper Craig On Tue, 16 Dec 2003, Ted Husted wrote: With this proposal, I took a middle ground. The initial minor release (x.x.0) in a series called for a vote on a plan, but a plan would be optional for additional releases in the same series (1.2.1, 1.2.2, ...). So, we wouldn't have to vote on a plan again until we get to 1.3.0 or 2.0.0. The rationale is that starting a new series (1.2.0 versus 1.1.0) is a decision upon which we should have a formal consensus. After that, issuing additional point releases in the same series can be business as usual . Of course, this is just a vote on the plan. Once we roll the release, there would be another vote on whether to take that specific entity from Alpha to Beta and/or General Availability. (Though, personally, I prefer the more common stable designation to GA.) Of course, as the HTTPD guidelines point out, under the Apache License, anyone can distribute a release of our codebase. It's just a matter of whether it can be called Struts or not. :) -Ted, Martin Cooper wrote: +1 I've added myself as an RM, since I'll be available to help. I can take on the tag, roll, sign and announce part, if you like. One thing I'd like to point out, because it came up in Commons, is that the HTTPD process and the Jakarta process are not 100% compatible. In particular, the Jakarta rules require a vote, while the HTTPD rules do not. I suspect that this vote may be sufficient, but I'll check when I get a chance. -- Martin Cooper On Tue, 16 Dec 2003, Ted Husted wrote: I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [VOTE] 1.2.0 Release Plan
Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Wish I could shed some light on this, but I haven't been able to figure out what changed in our configuration to cause the cactus tests to fail for any of the tests that I wrote. We upgraded the version of Cactus. It was passing with 1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
Comments in line. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, December 8, 2003 09:56 PM To: 'Struts Developers List' Subject: Test Case Exception Throwing style (Re: Cactus tests) I would suggest that the proper behavior here is to throw the exception and let JUnit deal with it as an error rather than a failure. This puts the actual error in the test report, which makes it a lot easier to solve the problem. +1 sounds good. For what it's worth, I've got it passing 71/97 tests clear, and the rest fall into two categories: 19 with failures because the context-path of the test app is hardcoded as test and the plugin uses struts-cactus, and 7 that have to do with cookie values. If anyone has any clever ideas for the simplest way to extract the context path The context path used for the test is stored in the build.properties file. Couldn't those properties be read in by the unit tests ? Right now they are used to modify the server.xml file by using ant filtering while copying. Also if you look at the CVS history of those files with a hard coded 'test' context you'll probably see the path change from /test/xyz/abc.jsp - /xyz/abc.jsp - /test/xyz/abc.jsp Why this occured I couldn't tell you. without using the tags which are being tested, I'm all ears...the cookie thing is totally baffling at the moment. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should Validator use a .js file script?
This is a struts-user question, it will be answered there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2003 07:27 PM To: 'Struts Developers List' Subject: Should Validator use a .js file script? Hello guys, I'm wondering why does the Validator tag html:javascript/ prints out all the validation scripts instead of only the required javascript functions. This could be ever better: there could be a .js file with all the scripts for avoiding sending the validation scripts at each page, enabling the browser to cache its content. When talking about a high scale application, this *does* matter. Thank you guys, and continue the great work! Stutz - 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]
Fwd: Declared Exceptions and Chained Exceptions
I didn't get a response from the User List - so maybe one of you
gents will know the answer.
Thanks,
Matt
--- In [EMAIL PROTECTED], Matt Raible [EMAIL PROTECTED] wrote:
Can I use Declarative Exceptions and Chained Exceptions at the same
time? I'd love to be a able to specify a list of exceptions in my
struts-config.xml, and have those errors stacked on each other.
Currently, I'm rendering ChainedExceptions using the following, and
would love to do it in struts-config.xml instead. Any advice or
suggestions are appreciated.
try {
UserManager mgr =
new UserManagerImpl(
(String) ctx.getAttribute(Constants.DAO_TYPE));
UserForm user = mgr.getUser(username);
session.setAttribute(Constants.USER_KEY, user);
} catch (Exception e) {
log.error(Error getting user's information + e);
e.printStackTrace();
ActionErrors errors = new ActionErrors();
errors.add(
ActionErrors.GLOBAL_ERROR,
new ActionError(errors.general));
StringBuffer sb = new StringBuffer();
if (e.getCause() == null) {
sb.append(e.getMessage());
} else {
while (e.getCause() != null) {
sb.append(e.getMessage());
e = (Exception) e.getCause();
}
}
errors.add(
ActionErrors.GLOBAL_ERROR,
new ActionError(errors.detail, sb.toString()));
}
Thanks,
Matt
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe@j...
For additional commands, e-mail: mailto:struts-user-help@j...
--- End forwarded message ---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
struts and pdf files
Hi everyone, I have a pb with struts and pdf files; when I try to load a pdf file troughout an action forward path=/pdf/file.pdf , it doesn't load !? Anyone knows how to deal with it? Mamadou FALL -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts Layout problem
Hello, I encounter a problem with the implementation of the struts layout dynmenu I tried with the example source from http://struts.application-servers.com/ but it doesn't work. layout:dynMenu config=org.apache.struts.webapp.example.Mainmenu left=100 top=150 layout:menuItem key=menu.test.menu1 link=link1.html/ layout:menuItem key=menu.test.menu2 layout:menuItem key=menu.test.item1 link=link2.html/ layout:menuItem key=menu.test.item2 link=link3.html/ /layout:menuItem layout:menuItem key=menu.test.menu3 layout:menuItem key=menu.test.menu4 layout:menuItem key=menu.test.item3 link=link4.html/ layout:menuItem key=menu.test.item4 link=link5.html/ /layout:menuItem layout:menuItem key=menu.test.item5 link=link6.html/ /layout:menuItem layout:menuItem key=menu.test.menu5 link=link7.html/ /layout:dynMenu I tried to create a configuration file named Mainmenu but I still have the following error : javax.servlet.ServletException: com/fgm/web/menu/MenuBase Thank for your help Jean-Rémy GALLAPONT SchlumbergerSema Ingénieur chargé d'études Tel: 04.97.15.79.20 [EMAIL PROTECTED] 150, Allée Pierre Ziller - Les Bouillides BP279 - 06905 Sophia-Antipolis Cedex Fax: 04.94.15.89.01 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
