RE: Declarative exception handling for Action classes

[Laine Donlan]

>If we had thought of this when first designing Struts, that would have
>made sense.  But now, I would be ***really*** hesitant to change the
>method signature for Action.perform() and potentially break everybody's
>existing implementations.

I guess that makes perfect sense, wouldn't want to break everything that
already exists.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Declarative exception handling for Action classes

[Craig R. McClanahan]

On Thu, 1 Nov 2001, Laine Donlan wrote:

> Date: Thu, 1 Nov 2001 16:44:06 -0500
> From: Laine Donlan <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Declarative exception handling for Action classes
>
> >> - As an alternative to passing the exception you are throwing under
> >>   a particular request or session scope key, how about having your
> >>   Action simply wrap the business logic exception inside a
> >>   ServletException (as the root cause) and throw that?  The perform
> >>   method already declares "throws ServletException", and we could
> >>   enhance the controller servlet to simply do its exception mapping
> >>   trick on any exception thrown by the perform method.
>
> >This seems like a good idea to me.  People who want the "throws
> Exception"
> >semantics can easily achieve it by subclassing Action and doing a try{}
> >catch{} in there, and then having all their actions extend the
> subclass.
>
> I guess my thinking here is if the controller is always going to do
> something like
> try{
> }catch(SevletException ser){
> do something with ser.getRootCause()
> }
>
> Then why not force the issue of the ServletException and allow for
> actions to throw Exception.
> If an exception is thrown that has not be mapped to an action, then it
> will be wrapped in
> ServletException and re-thrown - then it will be available for the
> normal 
> type handling by the container.
>

If we had thought of this when first designing Struts, that would have
made sense.  But now, I would be ***really*** hesitant to change the
method signature for Action.perform() and potentially break everybody's
existing implementations.

However, it's still easy for an Action to throw an arbitrary exception
simply by encapsulating it:

  try {
...
  } catch (RemoteException e) {  // Just as an example
throw new ServletException(e);
  }

In Servlet 2.3 containers, the  type handling actually does
use the "root cause" exception to base its decision on, if you haven't
mapped anything to ServletException itself.  The rules are spelled out in
Section 9.9.2 of the 2.3 spec.  But the benefits of being able to define
this per-Action is a good reason to make the mappings configurable within
Struts itself.

>
> Laine
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Declarative exception handling for Action classes

[Laine Donlan]

>> - As an alternative to passing the exception you are throwing under
>>   a particular request or session scope key, how about having your
>>   Action simply wrap the business logic exception inside a
>>   ServletException (as the root cause) and throw that?  The perform
>>   method already declares "throws ServletException", and we could
>>   enhance the controller servlet to simply do its exception mapping
>>   trick on any exception thrown by the perform method.

>This seems like a good idea to me.  People who want the "throws
Exception"
>semantics can easily achieve it by subclassing Action and doing a try{}
>catch{} in there, and then having all their actions extend the
subclass.

I guess my thinking here is if the controller is always going to do
something like
try{
}catch(SevletException ser){
do something with ser.getRootCause()
}

Then why not force the issue of the ServletException and allow for
actions to throw Exception.  
If an exception is thrown that has not be mapped to an action, then it
will be wrapped in 
ServletException and re-thrown - then it will be available for the
normal 
type handling by the container.

>> But, given all of the above, if you have your actions throw a
business
>> logic exception wrapped in a servlet exception, is there something
needed
>> that the standard  mechanism does not handle for you?
The
>> only thing I can think of would be the global/local mapping option
(which
>> is probably a good enough reason to do this), but the standard
mechanism
>> seems to be pretty complete.
I think that the action level granularity is what we will be buying.  I
do agree
that the built in error-page functionality could be utilized for the
global type 
errors.  What would be lost will be the ability to define error keys,
etc. 


>Matching exceptions to handlers should check the inheritance
>hierarchy of the actual exception, but trying to match on the
>exact class first.  This is how the servlet container (at least
>for version 2.3 and beyond) match up exceptions when you define
>an  for a particular exception. 
This is pretty much how the code submitted would work.  The only 
difference would be that if the heirarchy has multiple layers, with
multiple exceptions from the
same hierarchy mapped, an exact match cannot be made - the first
exception found from which 
the thrown exception could be assigned win the search.


Laine


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Declarative exception handling for Action classes

[Craig R. McClanahan]

On Thu, 1 Nov 2001, Simon Sadedin wrote:

> Date: Thu, 1 Nov 2001 15:59:28 -0500
> From: Simon Sadedin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Declarative exception handling for Action classes
>
> > - If we pass the actual exception as attributes, I would suggest
> >   using request scope rather than session scope.  This will allow
> >   the technique to work even in apps that don't use sessions, and
> >   will also avoid problems when there are multiple simultaneous
> >   requests for a particular session.
>
> Maybe a "scope" type attribute like we use elsewhere?  Since our application
> makes heavy use of frames, putting stuff in the request doesn't always work
> (at least, not easily).

That makes sense.  I would still lobby for request scope as the default.

One thing I didn't comment on before -- do we really need more than one
key, or can we just use a single well-know key name?

>
> > - As an alternative to passing the exception you are throwing under
> >   a particular request or session scope key, how about having your
> >   Action simply wrap the business logic exception inside a
> >   ServletException (as the root cause) and throw that?  The perform
> >   method already declares "throws ServletException", and we could
> >   enhance the controller servlet to simply do its exception mapping
> >   trick on any exception thrown by the perform method.
>
> This seems like a good idea to me.  People who want the "throws Exception"
> semantics can easily achieve it by subclassing Action and doing a try{}
> catch{} in there, and then having all their actions extend the subclass.
>
> > But, given all of the above, if you have your actions throw a business
> > logic exception wrapped in a servlet exception, is there something needed
> > that the standard  mechanism does not handle for you?  The
> > only thing I can think of would be the global/local mapping option (which
> > is probably a good enough reason to do this), but the standard mechanism
> > seems to be pretty complete.
>
> I guess the difference would be that it can't be configured "per action"
> (right?) and its not integrated with struts style error messages from
> resources files (correct me if I'm wrong!).

Being able to do mapings per-Action would definitely be a reason to do
this inside of Struts (container managed exception pages are global to the
app).  I would suggest we support the "global and local" mappings for
this, just like we do with ActionForwards.

With regards to integration, the container-managed approach would easily
integrate, because it does create a request-scope attribute containing the
actual exception for you.  So it would be possible to integrate either
way.

>
> Cheers,
>
> Simon Sadedin.
>
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Declarative exception handling for Action classes

[Simon Sadedin]

> - If we pass the actual exception as attributes, I would suggest
>   using request scope rather than session scope.  This will allow
>   the technique to work even in apps that don't use sessions, and
>   will also avoid problems when there are multiple simultaneous
>   requests for a particular session.

Maybe a "scope" type attribute like we use elsewhere?  Since our application
makes heavy use of frames, putting stuff in the request doesn't always work
(at least, not easily).

> - As an alternative to passing the exception you are throwing under
>   a particular request or session scope key, how about having your
>   Action simply wrap the business logic exception inside a
>   ServletException (as the root cause) and throw that?  The perform
>   method already declares "throws ServletException", and we could
>   enhance the controller servlet to simply do its exception mapping
>   trick on any exception thrown by the perform method.

This seems like a good idea to me.  People who want the "throws Exception"
semantics can easily achieve it by subclassing Action and doing a try{}
catch{} in there, and then having all their actions extend the subclass.

> But, given all of the above, if you have your actions throw a business
> logic exception wrapped in a servlet exception, is there something needed
> that the standard  mechanism does not handle for you?  The
> only thing I can think of would be the global/local mapping option (which
> is probably a good enough reason to do this), but the standard mechanism
> seems to be pretty complete.

I guess the difference would be that it can't be configured "per action"
(right?) and its not integrated with struts style error messages from
resources files (correct me if I'm wrong!).

Cheers,

Simon Sadedin.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Declarative exception handling for Action classes

[Craig R. McClanahan]

I haven't played directly with this code yet, but the general concept
sounds very cool.  A couple of thoughts:

- If we pass the actual exception as attributes, I would suggest
  using request scope rather than session scope.  This will allow
  the technique to work even in apps that don't use sessions, and
  will also avoid problems when there are multiple simultaneous
  requests for a particular session.

- As an alternative to passing the exception you are throwing under
  a particular request or session scope key, how about having your
  Action simply wrap the business logic exception inside a
  ServletException (as the root cause) and throw that?  The perform
  method already declares "throws ServletException", and we could
  enhance the controller servlet to simply do its exception mapping
  trick on any exception thrown by the perform method.

- Matching exceptions to handlers should check the inheritance
  hierarchy of the actual exception, but trying to match on the
  exact class first.  This is how the servlet container (at least
  for version 2.3 and beyond) match up exceptions when you define
  an  for a particular exception.

- Given the change to just having your action throw the exception,
  defining global exception handlers with local overrides can be
  done in a manner similar to the way global forwards are defined
  with local overrides.

But, given all of the above, if you have your actions throw a business
logic exception wrapped in a servlet exception, is there something needed
that the standard  mechanism does not handle for you?  The
only thing I can think of would be the global/local mapping option (which
is probably a good enough reason to do this), but the standard mechanism
seems to be pretty complete.

Craig McClanahan



On Wed, 31 Oct 2001, Laine Donlan wrote:

> Date: Wed, 31 Oct 2001 22:06:06 -0500
> From: Laine Donlan <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Declarative exception handling for Action classes
>
>
> Wanted to submit the following code for comment from the Struts dev
> group.  Being faced with a pretty large development project and a
> development environment that oftentimes had one developer working on the
> Web tier code (Struts) and another developer working at the middle tier
> level (EJB's),  an attempt was made to alleviate the need to update
> action code and workflow to accommodate changes in the web tier/middle
> tier contract.
>
> Specifically this related to how business logic exceptions were defined
> and handled.  We have found that within our Struts actions we often see
> large amounts of business logic exception handling which usually does
> nothing more then configure a message and forward the user to some kind
> or error url or back to the previous page with a validation type error
> message.  Not only is this verbose and repetitious, but it is fragile to
> changes in the middle tier since every time a new exception is added, a
> struts-knowledgeable person needs go into all the struts code and add
> exception handling for it.  As with other repitious and tedious code,
> our feeling was that the best way to handle this was to allow for
> exception handling to be declarative and configurable through the
> struts-config.xml.  We have therefore created a scheme where exceptions
> are treated much the same as forwards in the current Struts code-line.
> Each action mapping can define any number of exceptions that may occur
> and how they should be handled.  The handling of the exceptions consists
> of the definition of a key value (error message, etc) , and a path
> (optional - input of the action would be the default).  When an
> exception occurs that can be handled the ActionException (consisting of
> key, and path) is placed into the user's session under a key constant -
> org.apache.struts.action.ACTION_EXCEPTION.  It can then be handled
> however is necessary by an app.
>
> Exception hierarchies are supported just as they would be in a typically
> try{}catch code block through an optional mapping parameter to determine
> whether or not to support the hierarchy.  When attempting to match and
> handle an exception first a specific match would be sought, if one could
> not be found, then a search for any assignable exception would be made.
> The first match would end the search.
>
> The following would be an example of an action mapping:
>
>name="someForm"
>   validate="false"
>   input="/someUri.">
>
>   
>   type="some.package.business.logic.Exception"/>
>   type="some.package.business.logic.Exception2"
>path="/someotherUri..."/>
>   type="java.lang.Exception"/>
>   type="javax.ejb.EjbException"
>hierarchachal="false"/>
> 
>
> The following outlines how each of the exceptions would be handled:
>
> 1) If an some.pac

Re: Declarative exception handling for Action classes

[Ted Husted]

I haven't tried the code, but assuming it works, I think I'm on board
here. 

The part about perform() throwing Exception gives me pause though. 

Does perform need to throw Exception, or does ActionController simply
need to catch Exception?

Why are EjbExceptions handled differently?

If this is a convenience for your project, can it arranged as a standard
alternative rather than the default?


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionError.java

[martinc]

martinc 01/10/31 23:08:41

  Modified:src/share/org/apache/struts/action Tag: STRUTS_1_0_BRANCH
ActionError.java
  Log:
  Added documentation on placeholder syntax.
  
  Submitted by: Tom Klaasen
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.1   +8 -4  
jakarta-struts/src/share/org/apache/struts/action/ActionError.java
  
  Index: ActionError.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionError.java,v
  retrieving revision 1.3
  retrieving revision 1.3.2.1
  diff -u -r1.3 -r1.3.2.1
  --- ActionError.java  2001/02/21 00:35:41 1.3
  +++ ActionError.java  2001/11/01 07:08:41 1.3.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionError.java,v 1.3 
2001/02/21 00:35:41 craigmcc Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/02/21 00:35:41 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionError.java,v 1.3.2.1 
2001/11/01 07:08:41 martinc Exp $
  + * $Revision: 1.3.2.1 $
  + * $Date: 2001/11/01 07:08:41 $
*
* 
*
  @@ -73,8 +73,12 @@
* message resources database) plus up to four placeholder objects that can
* be used for parametric replacement in the message text.
*
  + * The placeholder objects are referenced in the message text using the same
  + * syntax used by the JDK MessageFormat class. Thus, the first
  + * placeholder is '{0}', the second is '{1}', etc.
  + *
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2001/02/21 00:35:41 $
  + * @version $Revision: 1.3.2.1 $ $Date: 2001/11/01 07:08:41 $
*/
   
   public class ActionError implements Serializable {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Declarative exception handling for Action classes

[Trieu, Danny]

I would love to have this feature.

-Original Message-
From: Joe Faith [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 7:12 AM
To: Struts Developers List
Subject: Re: Declarative exception handling for Action classes


I was presuming that the default behaviour would be for the ActionServlet to
send the user back to the 'input' page on error; but these would be useful
optional
parameters.

Laine: would you consider incorporating this, or should I have a go myself?

"Deadman, Hal" wrote:

> Wouldn't Joe Faith's example have to support a forward or path attribute
so
> the action servlet would know where to forward to?
>
> 
>  forward="failure" />
> 
> or
> 
>  path="/error.jsp" />
> 

Joe Faith

Runtime Collective, Ltd
T: (+44) 01273 234294
www.runtime-collective.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Declarative exception handling for Action classes

[Laine Donlan]

I would like to incorporate any functions seen valuable.  I wanted to
get this out for some discussion first.  

I will attempt to add any thing suggested and can make them available.

Laine

-Original Message-
From: Joe Faith [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 10:12 AM
To: Struts Developers List
Subject: Re: Declarative exception handling for Action classes


I was presuming that the default behaviour would be for the
ActionServlet to
send the user back to the 'input' page on error; but these would be
useful
optional
parameters.

Laine: would you consider incorporating this, or should I have a go
myself?

"Deadman, Hal" wrote:

> Wouldn't Joe Faith's example have to support a forward or path
attribute so
> the action servlet would know where to forward to?
>
> 
>  forward="failure" />
> 
> or
> 
>  path="/error.jsp" />
> 

Joe Faith

Runtime Collective, Ltd
T: (+44) 01273 234294
www.runtime-collective.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Declarative exception handling for Action classes

[Joe Faith]

I was presuming that the default behaviour would be for the ActionServlet to
send the user back to the 'input' page on error; but these would be useful
optional
parameters.

Laine: would you consider incorporating this, or should I have a go myself?

"Deadman, Hal" wrote:

> Wouldn't Joe Faith's example have to support a forward or path attribute so
> the action servlet would know where to forward to?
>
> 
>  forward="failure" />
> 
> or
> 
>  path="/error.jsp" />
> 

Joe Faith

Runtime Collective, Ltd
T: (+44) 01273 234294
www.runtime-collective.com

RE: Declarative exception handling for Action classes

[Deadman, Hal]

I think this is a good idea. I also have similar repetative exception
handling in all of my action classes. Having global exceptions to handle
general system errors would be helpful. I might prefer to handle some
"expected" exceptions in my action class just to make the code easier to
read but I could do without having to trap Exception in every action class
and forwarding to a system error page.

Wouldn't Joe Faith's example have to support a forward or path attribute so
the action servlet would know where to forward to?




or




-Original Message-
From: faith [mailto:faith]On Behalf Of Joe Faith
Sent: Thursday, November 01, 2001 5:44 AM
To: Struts Developers List
Subject: Re: Declarative exception handling for Action classes


This looks useful, but would be even more so if you could include the
following type
of exception mapping:



 

The action servlet would then generate an ActionError and add it to the
request.
This would save a lot of code of the following type:

} catch (package.Exception e) {
 errors.add(ActionErrors.GLOBAL_ERROR, new
ActionError("some.error.key"));
 saveErrors(request, errors);
 return (mapping.findForward("failure"));
   }

which seems to take up half of my actions at the moment.

Laine Donlan wrote:

> Each action mapping can define any number of exceptions that may occur
> and how they should be handled.  The handling of the exceptions
consists
> of the definition of a key value (error message, etc) , and a path
> (optional - input of the action would be the default).  When an
> exception occurs that can be handled the ActionException (consisting
of
> key, and path) is placed into the user's session under a key constant
-
> org.apache.struts.action.ACTION_EXCEPTION.  It can then be handled
> however is necessary by an app.
> The following would be an example of an action mapping:
>
>  name="someForm"
> validate="false"
> input="/someUri.">
>
> 
>   type="some.package.business.logic.Exception"/>
>   type="some.package.business.logic.Exception2"
>  path="/someotherUri..."/>
>   type="java.lang.Exception"/>
>   type="javax.ejb.EjbException"
>  hierarchachal="false"/>
> 
>
> The following outlines how each of the exceptions would be handled:
>
> 1) If an some.package.business.logic.Exception is throw from the
Action
> perform method, the client will be dispatched to the input of the form
> with an ActionException placed into the session under a specific key.
>
> 2) If an some.package.business.logic.Exception2 is thrown, the client
> will be dispatched to the path specified in that mapping with the
> ActionException placed in the session.
>
> 3) If anything other than the previous 2 exception or an EjbException
is
> thrown, the client would be re-directed to the input of the form,
again
> with the ActionException placed into the session.
>
> 4) If an EjbException is thrown (it's children would not be handled by
> this) then the client would be dispatched with that ActionException in
> the session under a defined constant value.
>
> The changes to the code base consisted of:
>
> 1) Addition of ActionException and ActionExceptions classes.  Very
much
> like the existing mapping classes.
> 2) Change of the perform() method signature to throw Exception rather
> than IOException and ServletException
> 3) Update the processActionPerform() method of the ActionServlet
perform
> the try{}cactch{} and to map resultant exceptions.
> 4) Add the digesting into the ActionServlet init()
> 5) Add the ActionExceptions reference into the ActionMapping.
>
> I have attached the code:
>  <>
>
> As well as diffs of the changes to the ActionServlet and Action
classes
>  <>  <>
>
> A couple of major @todo's in the code would be the implementation of
> global-exceptions, and a currently hard-coded exception message in any
> unhandled exception that is wrapped into a ServletException.  I wanted
> to see if there was interest for this type of feature, if so I can
> easily put the rest of it together and submit it.
>
> Thanks, any comments or feedback would be appreciated.
>
>

>  Name: changes.zip
>  Type: Zip Compressed Data
(application/x-zip-compressed)
>changes.zip   Encoding: base64
>   Description: changes.zip
>   Download Status: Not downloaded with message
>
>  Name: Action-diff.txt
>Action-diff.txt   Type: Plain Text (text/plain)
>  Encoding: base64
>   Description: Action-diff.txt
>
> Name: ActionServlet-diff.txt
>ActionServlet-diff.txt   Type: Plain Text (text/plain)
>  

FW: Bug in DTD

[Pier Fumagalli]

Blocked by moderation to general@jakarta, but might be relevant.

Pier


-- Forwarded Message
From: "Irek Singer" <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2001 09:17:12 -0500
To: <[EMAIL PROTECTED]>
Subject: Bug in DTD

HI, 

I guess a new DTD has been put in repository, now it gives this error:

http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd

Cannot have a DTD declaration outside of a DTD. Line 26, Position 12



---^



-- End of Forwarded Message


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Declarative exception handling for Action classes

[Joe Faith]

This looks useful, but would be even more so if you could include the following type
of exception mapping:



 

The action servlet would then generate an ActionError and add it to the request.
This would save a lot of code of the following type:

} catch (package.Exception e) {
 errors.add(ActionErrors.GLOBAL_ERROR, new ActionError("some.error.key"));
 saveErrors(request, errors);
 return (mapping.findForward("failure"));
   }

which seems to take up half of my actions at the moment.

Laine Donlan wrote:

> Each action mapping can define any number of exceptions that may occur
> and how they should be handled.  The handling of the exceptions consists
> of the definition of a key value (error message, etc) , and a path
> (optional - input of the action would be the default).  When an
> exception occurs that can be handled the ActionException (consisting of
> key, and path) is placed into the user's session under a key constant -
> org.apache.struts.action.ACTION_EXCEPTION.  It can then be handled
> however is necessary by an app.
> The following would be an example of an action mapping:
>
>  name="someForm"
> validate="false"
> input="/someUri.">
>
> 
>   type="some.package.business.logic.Exception"/>
>   type="some.package.business.logic.Exception2"
>  path="/someotherUri..."/>
>   type="java.lang.Exception"/>
>   type="javax.ejb.EjbException"
>  hierarchachal="false"/>
> 
>
> The following outlines how each of the exceptions would be handled:
>
> 1) If an some.package.business.logic.Exception is throw from the Action
> perform method, the client will be dispatched to the input of the form
> with an ActionException placed into the session under a specific key.
>
> 2) If an some.package.business.logic.Exception2 is thrown, the client
> will be dispatched to the path specified in that mapping with the
> ActionException placed in the session.
>
> 3) If anything other than the previous 2 exception or an EjbException is
> thrown, the client would be re-directed to the input of the form, again
> with the ActionException placed into the session.
>
> 4) If an EjbException is thrown (it's children would not be handled by
> this) then the client would be dispatched with that ActionException in
> the session under a defined constant value.
>
> The changes to the code base consisted of:
>
> 1) Addition of ActionException and ActionExceptions classes.  Very much
> like the existing mapping classes.
> 2) Change of the perform() method signature to throw Exception rather
> than IOException and ServletException
> 3) Update the processActionPerform() method of the ActionServlet perform
> the try{}cactch{} and to map resultant exceptions.
> 4) Add the digesting into the ActionServlet init()
> 5) Add the ActionExceptions reference into the ActionMapping.
>
> I have attached the code:
>  <>
>
> As well as diffs of the changes to the ActionServlet and Action classes
>  <>  <>
>
> A couple of major @todo's in the code would be the implementation of
> global-exceptions, and a currently hard-coded exception message in any
> unhandled exception that is wrapped into a ServletException.  I wanted
> to see if there was interest for this type of feature, if so I can
> easily put the rest of it together and submit it.
>
> Thanks, any comments or feedback would be appreciated.
>
>   
>  Name: changes.zip
>  Type: Zip Compressed Data (application/x-zip-compressed)
>changes.zip   Encoding: base64
>   Description: changes.zip
>   Download Status: Not downloaded with message
>
>  Name: Action-diff.txt
>Action-diff.txt   Type: Plain Text (text/plain)
>  Encoding: base64
>   Description: Action-diff.txt
>
> Name: ActionServlet-diff.txt
>ActionServlet-diff.txt   Type: Plain Text (text/plain)
> Encoding: base64
>  Description: ActionServlet-diff.txt
>
>   
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--

Joe Faith

Runtime Collective, Ltd
T: (+44) 01273 234294