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 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]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
