Henning P. Schmiedehausen wrote:
Scott Eade <[EMAIL PROTECTED]> writes:
Do you have a comment on this Henning?
Hm. This was put in > two years ago. I do remember that I got this
from load testing one of our applications and that was the
solution. We were getting spurious ITEs without any real cause in the
application but out of the invoke() code. It raised no comment on the
-dev list back then (according to the archives).
Should we address it in 2.3.2? That code is in there ever since 2.3RC1
and the whole 2.3 cycle. Changing it would be actually changing
behaviour from previous 2.3 releases to 2.3.2. So I'd say cautiously
"no, not in the default". We might add a property to control this, but
this feels like a kludge.
I, as a turbine user I would vote for throwing the exception, otherwise
turbine doesn't redirect
the page to the error screen, when an exception occurs in Actions.
In other words, it hides probably the most important exceptions, those
that update the information in the database.
Best,
Sergiu
I will post the result of the vote today. I will hold the actual
rolling of the release until tomorrow to see if anyone else pipes
up. If you have a patch ready for review that would be even better.
Best regards
Henning
IMO this should be addressed for 2.3.2.
Scott
Scott Eade wrote:
It looks like Henning's change in revision 221603 is the culprit.
The commit message is:
Catch InvokationTargetExceptions and log them at error level. I was
able to provoke this by rapidly firing and aborting HTTP requests for
an action at a Tomcat server. Sooner or later, the container would get
out of step and suddently the invoked methods would disappear from the
class loader.
I was also thinking about
Throwable t = ite.getTargetException();
if (t instanceof Exception)
{
throw (Exception) t;
}
else
{
throw new TurbineException(t);
}
but decided against it, because this would be a spurious and hard to
reproduce (and debug) error reported by the users. Discussion wanted.
Another way of provoking this exception is to have an action method thus:
public void doThrowexception(RunData data, Context context)
throws Exception
{
throw new MyException(".doThrowexception() - Goody!");
}
Scott
Scott Eade wrote:
Should an exception thrown in an action result in execution of the
screen configured as "screen.error" in TurbineResources.properties?
I had kind of assumed that it should, but it certainly does not -
VelocityActionEvent simply logs the exception and then carries on as if
all is well. This is not that great because it means the user receives
no feedback that an exception has occurred.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]