ExceptionAware!
Chris Nokleberg wrote:
Joseph Ottinger wrote:
What I'd thought of was adding an extra method to Action and
ActionSupport. The Action method's signature might look like this:
public String handleException(Throwable t) throws Throwable;
The ActionSupport implementation:
public S
Well, the original context was in that of WW1.3 as opposed to WW2, but
that would work as well, and certainly be more flexible, I suppose, with
nicer behaviour towards those who already implemented the pattern in their
own actions.
On Mon, 3 Nov 2003, Chris Nokleberg wrote:
> Joseph Ottinger wrot
Joseph Ottinger wrote:
> What I'd thought of was adding an extra method to Action and
> ActionSupport. The Action method's signature might look like this:
>
> public String handleException(Throwable t) throws Throwable;
>
> The ActionSupport implementation:
>
> public String handleException(Thr
James Cook wrote:
I thought of a pointless insult. ;-)
We used this pattern in a large application and it worked well. BTW, for
Hani's edification
(http://www.jroller.com/page/fate/20031029#opensymphony_dirty_laundry),
this is not a toy application, but rather a large app that manages
billions of
Well, the pattern (I won't call it an anti-pattern) is to do something
like this:
public abstract class FooActionBase extends ActionSupport {
public doExecute() throws Exception {
try {
return process();
} catch(Exception blah) {
// maybe make a note of the error somewhere, o
> -Original Message-
> Behalf Of Joseph Ottinger
> What I'd thought of was adding an extra method to Action and
> ActionSupport. The Action method's signature might look like this:
> ...
> Thoughts? Insults? Points?
I thought of a pointless insult. ;-)
We used this pattern in a large app
Although my response is that you're not simply handling the exceptions:
you're providing a container-neutral routing point. The servlet container
doesn't enter into it.
On Mon, 3 Nov 2003, Hani Suleiman wrote:
> Same argument from me as to why this is a bad approach in ww2. It's
> reinventing an
Same argument from me as to why this is a bad approach in ww2. It's
reinventing an existing wheel. Sure, it's maybe a bit more convenient to
use than the built-in mechanism in the servlet container, but it's still
stepping on its toes and making things that little bit murkier.
Joseph Ottinger w
A client of mine has been trying out WW1.3 and the exception handling
around execute() yielded a question and suggestion. The issue is that
throwing exceptions either bubbles up to the webapp layer, or involves a
pattern where a common ActionSupport derivative wraps a method call in
various try/cat
Title: lil' tool to help w/ template refactoring
Hi folks!
I've been badly burned by a change in our domain model, and unfortunately I found out that refactoring a domain model after coding tons of velocity templates with forms that change the objects directly using a Model-Driven action is
I have made a component interceptor that works quite like that.
All I need to do in my actions is define the mapping from action
properties to spring bean names like this :
...
accountsDao=accountsDao
...
Another way to do this is to use the same enab
The functionality that I need right now is to define an error page for each
"section" (namespace) of my site. So if an uncaught exception occurs in any
Action or view within that section an error handling action will be
executed.
Handling exceptions from within execute() is not good enough. The
I had thought the components.xml file would be a natural integration
point for Spring factory beans. To this end, I have written my own
WebWork enabler interface and exposed our Spring factories this way. It
seems lighter weight and a more natural WebWork integration point than
coupling the web-tie
I'm sure that an exception handler mechanism for XWork is not necessary, but
an advantage that could satisfy a part of the WW community is not bad. I can
understand all of your points of view, but when a framework proposes an
optional valuable feature, it's obviously good to promote the framework.
14 matches
Mail list logo