saveErrors is not deprecated. I use it in Struts 1.2.
--- Asad Habib <[EMAIL PROTECTED]> wrote:
> Paul, what method do I use to save them? I am using Struts 1.2.9 and as
> far as I know the saveErrors method has been deprecated. Is there another
> method that replaced this one? Thanks.
>
> - A
Paul, what method do I use to save them? I am using Struts 1.2.9 and as
far as I know the saveErrors method has been deprecated. Is there another
method that replaced this one? Thanks.
- Asad
On Tue, 16 May 2006, Paul Benedict wrote:
Asad,
I have not had this problem. I use declarative exce
Asad,
I have not had this problem. I use declarative exception all the time.
Two things to look for:
1) Make sure you're actually saving the errors messages after you generate
them. Calling form.validate() only makes them; make sure you save them
in the request.
2) Make sure you're not redirect
On 4/21/06, Asad Habib <[EMAIL PROTECTED]> wrote:
> When using declarative exception handling, where do you create the
> exception instances? In the action itself?
Yes. The framework first catches all exceptions thrown by an Action.
Then, it looks to see if there's an exception handler for that
ex
Just to clarify for archive searchers.
The and work with declarative
programming. These tags were introduced to provide the programmer more
control over the formatting of the messages, compared to what
provide. For example, require HTML tags to be present in the
message itself in the applica
Thanks Hubert. If you see my last post, you'll see that I solved the
problem without having to write any Java code -- I did it all
declaratively and with tags. Nowhere in my code do I create
ActionMessages instances -- I am trying to let Struts do this for me,
and stick with declarative program
OK I solved the problem. The problem was that the html:errors tag that
is pulling messages from the default bundle apparently renders
errors.header and error.footer if *any* error message is stored as a
request attribute, no matter what bundle that error message might come
from. This seems wron
For validation errors, do the usual, using the saveErrors to pass them to the
JSP:
// validation error
ActionMessages actionMessages = new ActionMessages();
actionMessages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage("illegal.username", username));
saveErrors(request, actionMessages)
Well, this didn't work, the header and footer from the default bundle
are rendered even though there are no form validation errors, despite
that the displayed error message is from the other bundle! Perhaps the
errors.header and errors.footer are "inherited" from the default bundle
if they are
Seemingly a simple way to accomplish this would be to put the form
validation error messages into one properties file, and to define
errors.header and errors.footer for that file, and to put the non-form
validation error messages into a different properties file, and to *not*
define errors.head
That was a nice piece of information.
Thanks a lot Mat.
Regards,
Ashutosh
-Original Message-
From: Lowery, Mat [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 9:19 PM
To: Ashutosh Satyam; Struts Users Mailing List
Subject: RE: Declarative Exception handling
I use the Log Jakarta
I use the Log Jakarta Taglib in my error page like so:
http://jakarta.apache.org/taglibs/doc/log-doc/intro.html
-Original Message-
From: Ashutosh Satyam [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 6:39 AM
To: Struts Users Mailing List
Subject: Declarative Exception handling
12 matches
Mail list logo
