RE: Right way to extends Action
I would change the signature of the executeAction method not to throw Exception, but a
custom ActionException. This way, you would be able to be aware of what exceptions are
thrown in your action code.
i.e.
public abstract ActionForward executeAction(ActionMapping _mapping,
ActionForm _form,
HttpServletRequest _req,
HttpServletResponse _res) throws
MyActionException;
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:21 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hi,
In our application we use a similar concept :
- we have a class like this :
public abstract class BaseAction extends Action
In this class :
- we added some usefull field like a logger an a pointer to a singleton that
retains application's data
protected Log log = LogFactory.getLog(this.getClass());
protected static final Infos infos = Infos.getInstance();
- We change the modifier of the execute Method so as to be sure nobody use
it directly:
public final ActionForward execute(ActionMapping _mapping, ActionForm
_form, HttpServletRequest _req, HttpServletResponse _res) throws Exception {
- In this method we check the user session and log in information
- At the end of this method we call
return executeAction(_mapping, _form, _req, _res);
- This method executeAction is defined as this :
public abstract ActionForward executeAction(ActionMapping _mapping,
ActionForm _form, HttpServletRequest _req, HttpServletResponse _res) throws
Exception;
- So when we create a new action, we extend BaseAction and implement the
abstract method executeAction
This way, we have automatic user login check, and a logger at disposition.
regards,
Xavier
- Original Message -
From: niksa_os [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 1:45 PM
Subject: Right way to extends Action
I want all my Actions to extend BaseAction.
In BaseAction I want to check user session and to put some data in it, if
that data doesn't exist.
Is it good way:
public class SomeAction extends BaseAction {
public ActionForward execute( ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response ) {
super.execute( mapping,form, request, response);
OK, proceed ...
public class BaseAction extends BaseAction {
public ActionForward execute( ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response ) {
if (userSession is wrong) {
-try -- put data in session
-catch -- return mapping.findForward(wrongSession);}
else return null; //everything is OK
What you think about this way and is there better way to extend Action?
Thanks.
-
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 Problem Action Class
I am having the same problem shortly. I am thinking of the following solution: First, you'll need to inherit from all the action type classes you'll need in your application. Action DispatchAction SwitchAction YY Y MyActionMyDispatchActionMySwitchAction From this custom layer, use delegation to call common to all actions functionality. Then, you write this functionality just once, and it is actiontype independent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class I had faced simalr problem.. We have our own AbstractAction and other action hierarchy..And i still wabnted to use the action classes from Scaffold package(FindForward action etc..) But what I have done is I am using those action classes as they are,they do not belong to my applications action hierarchy..And that makes sense.. BEcause most of those action classes are utility classes .So they do not belong to your applications action hierarchy.And even if they do not extend from the AbstractAction of u r appliaction, u will not have any problem.BEcause they are necven called directly.They are used some where in the application flow as utility classes. hope this helps, Shirish -Original Message- From: Navjot Singh [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:28 PM To: Struts Users List Subject: Design Problem Action Class Hi geeks, I have class hierarchy like this. CustomerAction Y AppAction Y Action Now that i have seen DisapatchAction, I wish to use it for my further actionclasses. BUT the problem is DispatchAction extends Action. One way i can think of is to change AppAction to start extending DisptachAction. BUT all of my classes don't need the functionality of DisptachAction. Just a few need this functionality. How can I go about it? regards Navjot Singh - 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: Design Problem Action Class
Yes, delegation is the common alternative for multiple inheritance. If you are using IntelliJ, you can use the Code / Delegate Methods menu option. It will write the methods for you :) -Original Message- From: Navjot Singh [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:59 PM To: Struts Users Mailing List Subject: Re: Design Problem Action Class so this is the only solution i was thinking if somehow i can 2 extend classes. ;-) __C++ was good__ - Original Message - From: Dario Geier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 6:26 PM Subject: RE: Design Problem Action Class I am having the same problem shortly. I am thinking of the following solution: First, you'll need to inherit from all the action type classes you'll need in your application. Action DispatchAction SwitchAction Y YY MyAction MyDispatchAction MySwitchAction From this custom layer, use delegation to call common to all actions functionality. Then, you write this functionality just once, and it is actiontype independent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class I had faced simalr problem.. We have our own AbstractAction and other action hierarchy..And i still wabnted to use the action classes from Scaffold package(FindForward action etc..) But what I have done is I am using those action classes as they are,they do not belong to my applications action hierarchy..And that makes sense.. BEcause most of those action classes are utility classes .So they do not belong to your applications action hierarchy.And even if they do not extend from the AbstractAction of u r appliaction, u will not have any problem.BEcause they are necven called directly.They are used some where in the application flow as utility classes. hope this helps, Shirish -Original Message- From: Navjot Singh [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:28 PM To: Struts Users List Subject: Design Problem Action Class Hi geeks, I have class hierarchy like this. CustomerAction Y AppAction Y Action Now that i have seen DisapatchAction, I wish to use it for my further actionclasses. BUT the problem is DispatchAction extends Action. One way i can think of is to change AppAction to start extending DisptachAction. BUT all of my classes don't need the functionality of DisptachAction. Just a few need this functionality. How can I go about it? regards Navjot Singh - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design Problem Action Class
What I meant by delegation is using a different ActionUtility class. The base executeAction / performAction method implementation could be implemented as a Template method, where you call your checkForLogin and other methods as you wish. I am not calling other actions, but a neutral independent class. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class But I dont get the point of extending those Helper Actions... Becasue those helper classes will never fulfill a request on thier own..So ultimately whtever is the application logic in your base action(Like login check etc..)will be executed as the call finally goes to some Other applicationAction... And Also I am not sure what u mean by delegation here..But beware...If u mean caling one action which does all of this from all other actions, it is stringly discouraged in struts..Use of Actions as APIs is strongly discouraged.. -Original Message- From: Dario Geier [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:56 PM To: Struts Users Mailing List Subject: RE: Design Problem Action Class I am having the same problem shortly. I am thinking of the following solution: First, you'll need to inherit from all the action type classes you'll need in your application. Action DispatchAction SwitchAction YY Y MyActionMyDispatchActionMySwitchAction From this custom layer, use delegation to call common to all actions functionality. Then, you write this functionality just once, and it is actiontype independent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class I had faced simalr problem.. We have our own AbstractAction and other action hierarchy..And i still wabnted to use the action classes from Scaffold package(FindForward action etc..) But what I have done is I am using those action classes as they are,they do not belong to my applications action hierarchy..And that makes sense.. BEcause most of those action classes are utility classes .So they do not belong to your applications action hierarchy.And even if they do not extend from the AbstractAction of u r appliaction, u will not have any problem.BEcause they are necven called directly.They are used some where in the application flow as utility classes. hope this helps, Shirish -Original Message- From: Navjot Singh [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:28 PM To: Struts Users List Subject: Design Problem Action Class Hi geeks, I have class hierarchy like this. CustomerAction Y AppAction Y Action Now that i have seen DisapatchAction, I wish to use it for my further actionclasses. BUT the problem is DispatchAction extends Action. One way i can think of is to change AppAction to start extending DisptachAction. BUT all of my classes don't need the functionality of DisptachAction. Just a few need this functionality. How can I go about it? regards Navjot Singh - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design Problem Action Class
Well, that depends on your implementation. If need to perform any checkings (like checking whether the user has logged in) before any or almost any action you perform, then you'll need this customed layer (i.e. you'll call the ActionUtility.checkLoggedUser() method before calling executeAction in every BaseAction class). Even you can use them for customizing your logging. This is not too much work, and it could be of great use in the future. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:39 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class this sounds good idea...But still I dont see any reason to extend those helpr classes..U can use them out of the box :-)) -Original Message- From: Dario Geier [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:20 PM To: Struts Users Mailing List Subject: RE: Design Problem Action Class What I meant by delegation is using a different ActionUtility class. The base executeAction / performAction method implementation could be implemented as a Template method, where you call your checkForLogin and other methods as you wish. I am not calling other actions, but a neutral independent class. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class But I dont get the point of extending those Helper Actions... Becasue those helper classes will never fulfill a request on thier own..So ultimately whtever is the application logic in your base action(Like login check etc..)will be executed as the call finally goes to some Other applicationAction... And Also I am not sure what u mean by delegation here..But beware...If u mean caling one action which does all of this from all other actions, it is stringly discouraged in struts..Use of Actions as APIs is strongly discouraged.. -Original Message- From: Dario Geier [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:56 PM To: Struts Users Mailing List Subject: RE: Design Problem Action Class I am having the same problem shortly. I am thinking of the following solution: First, you'll need to inherit from all the action type classes you'll need in your application. Action DispatchAction SwitchAction YY Y MyActionMyDispatchActionMySwitchAction From this custom layer, use delegation to call common to all actions functionality. Then, you write this functionality just once, and it is actiontype independent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: RE: Design Problem Action Class I had faced simalr problem.. We have our own AbstractAction and other action hierarchy..And i still wabnted to use the action classes from Scaffold package(FindForward action etc..) But what I have done is I am using those action classes as they are,they do not belong to my applications action hierarchy..And that makes sense.. BEcause most of those action classes are utility classes .So they do not belong to your applications action hierarchy.And even if they do not extend from the AbstractAction of u r appliaction, u will not have any problem.BEcause they are necven called directly.They are used some where in the application flow as utility classes. hope this helps, Shirish -Original Message- From: Navjot Singh [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:28 PM To: Struts Users List Subject: Design Problem Action Class Hi geeks, I have class hierarchy like this. CustomerAction Y AppAction Y Action Now that i have seen DisapatchAction, I wish to use it for my further actionclasses. BUT the problem is DispatchAction extends Action. One way i can think of is to change AppAction to start extending DisptachAction. BUT all of my classes don't need the functionality of DisptachAction. Just a few need this functionality. How can I go about it? regards Navjot Singh - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Right way to extends Action
Ho Xavier,
so, how do you know which exception are thrown? You'll discover them at runtime :(
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 5:40 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hi,
Why have we choose to raise Execption on our BaseAction ?
Because, as was designed the execute method of the Action class, the
exceptions raised in an action class are passed back to the ActionSevlet,
who can handle all the exceptions that we have defined in the Struts config
file.
Xavier
- Original Message -
From: Dario Geier [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 2:41 PM
Subject: RE: Right way to extends Action
I would change the signature of the executeAction method not to throw
Exception, but a custom ActionException. This way, you would be able to be
aware of what exceptions are thrown in your action code.
i.e.
public abstract ActionForward executeAction( ActionMapping _mapping,
ActionForm _form,
HttpServletRequest _req,
HttpServletResponse _res) throws MyActionException;
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:21 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hi,
In our application we use a similar concept :
- we have a class like this :
public abstract class BaseAction extends Action
In this class :
- we added some usefull field like a logger an a pointer to a singleton that
retains application's data
protected Log log = LogFactory.getLog(this.getClass());
protected static final Infos infos = Infos.getInstance();
- We change the modifier of the execute Method so as to be sure nobody use
it directly:
public final ActionForward execute(ActionMapping _mapping, ActionForm
_form, HttpServletRequest _req, HttpServletResponse _res) throws Exception {
- In this method we check the user session and log in information
- At the end of this method we call
return executeAction(_mapping, _form, _req, _res);
- This method executeAction is defined as this :
public abstract ActionForward executeAction(ActionMapping _mapping,
ActionForm _form, HttpServletRequest _req, HttpServletResponse _res) throws
Exception;
- So when we create a new action, we extend BaseAction and implement the
abstract method executeAction
This way, we have automatic user login check, and a logger at disposition.
regards,
Xavier
- Original Message -
From: niksa_os [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 1:45 PM
Subject: Right way to extends Action
I want all my Actions to extend BaseAction.
In BaseAction I want to check user session and to put some data in it, if
that data doesn't exist.
Is it good way:
public class SomeAction extends BaseAction {
public ActionForward execute( ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response ) {
super.execute( mapping,form, request, response);
OK, proceed ...
public class BaseAction extends BaseAction {
public ActionForward execute( ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response ) {
if (userSession is wrong) {
-try -- put data in session
-catch -- return mapping.findForward(wrongSession);}
else return null; //everything is OK
What you think about this way and is there better way to extend Action?
Thanks.
-
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: Right way to extends Action
Yes, I know that, but still, and this is a true question.
If you throw java.lang.Exception on your executeAction, then, how do you know which
exceptions to declare in the config.xml?
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 6:22 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hum...
To my modest opinion, this is how Struts is designed.
The execute method of the Action class raise Exception.
For exemple when I implement an action that can raise an
IdentificationException, I have to register an ExceptionHandler for this
exception in the corresponding action
Here is 2 extracts from the struts-config_1_1.dtd concerning this point :
!ELEMENT action (icon?, display-name?, description?, set-property*,
exception*, forward*)
And the comment about execption :
!-- The exception element registers an ExceptionHandler for an exception
type.
The following attributes are defined:
bundle Servlet context attribute for the message resources
bundle
associated with this handler. The default attribute is
the
value specified by the string constant declared at
Globals.MESSAGES_KEY.
[org.apache.struts.Globals.MESSAGES_KEY]
classNameThe configuration bean for this ExceptionHandler
object.
If specified, className must be a subclass of the
default
configuration bean
[org.apache.struts.config.ExceptionConfig]
handler Fully qualified Java class name for this exception
handler.
[org.apache.struts.action.ExceptionHandler]
key The key to use with this handler's message resource
bundle
that will retrieve the error message template for this
exception.
path The module-relative URI to the resource that will
complete
the request/response if this exception occurs.
scopeThe context (request or session) that is used to
access
the ActionError object
[org.apache.struts.action.ActionError]
for this exception.
type Fully qualified Java class name of the exception type
to
register with this handler.
--
regards
- Original Message -
From: Dario Geier [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 4:41 PM
Subject: RE: Right way to extends Action
Ho Xavier,
so, how do you know which exception are thrown? You'll discover them at
runtime :(
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 5:40 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hi,
Why have we choose to raise Execption on our BaseAction ?
Because, as was designed the execute method of the Action class, the
exceptions raised in an action class are passed back to the ActionSevlet,
who can handle all the exceptions that we have defined in the Struts config
file.
Xavier
- Original Message -
From: Dario Geier [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 2:41 PM
Subject: RE: Right way to extends Action
I would change the signature of the executeAction method not to throw
Exception, but a custom ActionException. This way, you would be able to be
aware of what exceptions are thrown in your action code.
i.e.
public abstract ActionForward executeAction( ActionMapping _mapping,
ActionForm _form,
HttpServletRequest _req,
HttpServletResponse _res) throws MyActionException;
-Original Message-
From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:21 PM
To: Struts Users Mailing List
Subject: Re: Right way to extends Action
Hi,
In our application we use a similar concept :
- we have a class like this :
public abstract class BaseAction extends Action
In this class :
- we added some usefull field like a logger an a pointer to a singleton that
retains application's data
protected Log log = LogFactory.getLog(this.getClass());
protected static final Infos infos = Infos.getInstance();
- We change the modifier of the execute Method so as to be sure nobody use
it directly:
public final ActionForward execute(ActionMapping _mapping, ActionForm
_form, HttpServletRequest _req, HttpServletResponse _res) throws Exception {
- In this method we check the user session and log in information
- At the end of this method we call
return executeAction(_mapping, _form, _req, _res);
- This method executeAction is defined as this :
public abstract ActionForward executeAction(ActionMapping _mapping,
ActionForm _form, HttpServletRequest _req, HttpServletResponse _res) throws
Exception;
- So when we create a new action, we extend BaseAction
RE: Right way to extends Action
Ok, but still.how do you know about all the exceptions thrown by libraries or APIs you use? Part or most of them you'll reallize just on runtime -Original Message- From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 7:29 PM To: Struts Users Mailing List Subject: Re: Right way to extends Action For example, in my BaseAction class, when we verify that the user is logged in : if this is not the case, = throw new IdentificationException(); In the Struts config file (or locally to the action) we add : global-exceptions exception type=com.aaa.common.indentification.IdentificationException path=/login.do key=error.identification.notlogin/ /global-exception When the IdentificationException is raised it is always intercepted by the ActionServlet because it throws Exception. And this is the ActionServlet job to find if a matching exception declaration is present in the config file so as to redirect the response accordingly. Regards, Xavier - Original Message - From: Dario Geier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 5:32 PM Subject: RE: Right way to extends Action Yes, I know that, but still, and this is a true question. If you throw java.lang.Exception on your executeAction, then, how do you know which exceptions to declare in the config.xml? -Original Message- From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 6:22 PM To: Struts Users Mailing List Subject: Re: Right way to extends Action Hum... To my modest opinion, this is how Struts is designed. The execute method of the Action class raise Exception. For exemple when I implement an action that can raise an IdentificationException, I have to register an ExceptionHandler for this exception in the corresponding action Here is 2 extracts from the struts-config_1_1.dtd concerning this point : !ELEMENT action (icon?, display-name?, description?, set-property*, exception*, forward*) And the comment about execption : !-- The exception element registers an ExceptionHandler for an exception type. The following attributes are defined: bundle Servlet context attribute for the message resources bundle associated with this handler. The default attribute is the value specified by the string constant declared at Globals.MESSAGES_KEY. [org.apache.struts.Globals.MESSAGES_KEY] classNameThe configuration bean for this ExceptionHandler object. If specified, className must be a subclass of the default configuration bean [org.apache.struts.config.ExceptionConfig] handler Fully qualified Java class name for this exception handler. [org.apache.struts.action.ExceptionHandler] key The key to use with this handler's message resource bundle that will retrieve the error message template for this exception. path The module-relative URI to the resource that will complete the request/response if this exception occurs. scopeThe context (request or session) that is used to access the ActionError object [org.apache.struts.action.ActionError] for this exception. type Fully qualified Java class name of the exception type to register with this handler. -- regards - Original Message - From: Dario Geier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:41 PM Subject: RE: Right way to extends Action Ho Xavier, so, how do you know which exception are thrown? You'll discover them at runtime :( -Original Message- From: Xavier Saint-Denis [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 5:40 PM To: Struts Users Mailing List Subject: Re: Right way to extends Action Hi, Why have we choose to raise Execption on our BaseAction ? Because, as was designed the execute method of the Action class, the exceptions raised in an action class are passed back to the ActionSevlet, who can handle all the exceptions that we have defined in the Struts config file. Xavier - Original Message - From: Dario Geier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:41 PM Subject: RE: Right way to extends Action I would change the signature of the executeAction method not to throw Exception, but a custom ActionException. This way, you would be able to be aware of what exceptions are thrown in your action code. i.e. public abstract ActionForward executeAction( ActionMapping _mapping, ActionForm _form, HttpServletRequest _req, HttpServletResponse _res) throws MyActionException; -Original Message- From
Error Properties for Declarative Exception Handling
I would like to know if is there any way to add the ActionError property parameter in the Exception definition in the struts-config.xml file. I see that the DTD defines how to specify the message key for the Error, so I presumed that there should be a way to specify the property too, as for adding the error like: errors.add(password, new ActionError(error.user.signin.invalidpassword)); Then, I could set that all password related errors be printed in the same place in the JSP file. I see that the ExceptionHandler class takes the property field from the ModuleException or from the Error's message key, but nothing about the ExceptionConfig class. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
