Review Handler Collection logic around InvocationType

[joakime]

Jetty version(s)
12.0.6

Jetty Environment
Any

Java version/vendor (use: java -version)
Any

OS type/version
Any

Description
While reviewing PR #11412 a question about the InvocationType logic in the various Handler Collection implementations was brought up.

See

• Handler.Sequence.setHandlers()
• PathMappingsHandler.addMapping()
• Handler.Singleton.updateHandler()
• HotSwapHandler.setHandler()
• WebSocketUpgradeHandler

[gregw]

see also #12266

[gregw]

@joakime can you describe a bit more what this issue is about? If I look at Handler.Sequence I see:

        @Override
        public InvocationType getInvocationType()
        {
            if (isDynamic())
                return InvocationType.BLOCKING;

            InvocationType invocationType = InvocationType.NON_BLOCKING;
            for (Handler handler : _handlers)
                invocationType = Invocable.combine(invocationType, handler.getInvocationType());
            return invocationType;
        }

Which is not very efficient, but appears to be correct. So is this issue about efficiency or correctness?

[joakime]

@joakime can you describe a bit more what this issue is about? If I look at Handler.Sequence I see:

    @Override
    public InvocationType getInvocationType()
    {
        if (isDynamic())
            return InvocationType.BLOCKING;

        InvocationType invocationType = InvocationType.NON_BLOCKING;
        for (Handler handler : _handlers)
            invocationType = Invocable.combine(invocationType, handler.getInvocationType());
        return invocationType;
    }

Which is not very efficient, but appears to be correct. So is this issue about efficiency or correctness?

I filed this on behalf of @sbordet while we were reviewing PR #11412

It started as a result of trying to understand the lines ...

https://github.com/jetty/jetty.project/pull/11412/files#diff-e0bc618a8172099d95fe05f49ee72348860104e3d6b5c5048731b39640d1f79dR82-R87

And how they interacted with the various Handler collections behaviors too.
IIRC, Simone wanted there to be only 1 place to handle InvocationType, the handler itself, not the implementations that extend from the handlers.