Re: Migration to 2.3.20 - Issue with UnknownHandler and ConventionPlugin

[Thim Anneessens]

I suspected this was an oversigth. Looking forward for the definitive fix.

Thanks for the feedback Łukasz.
Best regards,
Thim.

On 12/19/2014 09:56 AM, Lukasz Lenart wrote:

Thanks Tim!

Great that you was able to find the same solution as described here [1] - to put some more details here: - the issue was with default implementation of UnknownHandler which was throwing NPE by default (throw null) - that's why everything was fine before 2.3.20, DefaultActionInvocation always got an exception when was calling UnknownHandlers - because of NPE it wasn't possible to have any other UnknownHandlers - the default one was always breaking the flow - after fixing NPE, I've overlooked this flow in DAI - it was expecting an exception

In the mentioned issue I've already proposed solution and Senen de Diego has also proposed some additional idea - I'm working on this right now and it will be released soon.

[1] https://issues.apache.org/jira/browse/WW-4433


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2014-12-19 8:48 GMT+01:00 Thim Anneessens <t.anneess...@ictjob.be <mailto:t.anneess...@ictjob.be>>:

    After a little fiddling we succeeded to migrate from 2.3.16 to
    2.3.20. Everything seemed fine until we had an exception in one
    action and noticed that something had changed.

    Exception thrown from an action got lost. It did not reach the
    interceptor in charge of exception handling because...

* The DefaultActionInvocation catched the exception and tried the unkownHandlerManager.handleUnknownMethod method.

      * DefaultActionInvocation tried the
        unkownHandlerManager.handleUnknownMethod method because we use
        the struts-convention plugin (same version) and that this
        plugin define the ConventionUnknownHandler bean.
      * Because the ConventionUnkownHandler.handleUnknownActionMethod
        does not do anything (it return null and has a big comment
        saying "Not used", which is obviously wrong :) ), the result
        code for the action is null.

    So we fixed this by adding our own UnkownHandler which throws a
    NoSuchMethodException which makes the DefaultActionInvocation
    throw our original exception. Problem solved, but (there is always
    a but)

     1. Maybe somebody could use this patch
     2. I do not understand why the "convention" behavior should be to
        ignore action exception and stopping them to spread through
        the interceptor stack as they did
     3. I think that this behavior should be changed in the
        DefaultActionInvocation. It feels unnatural to have to throw a
        NoSuchMethodException from an UnkownHandler in order to force
        the DefaultActionInvocation to throw our original exception.


    Anyway great release, allot of great improvements. Thanks to all
    committers for a great release.

-- *Thim Anneessens

    IT Department *

    ictjob group

--
*Thim Anneessens
IT Department *

ictjob group