Provide a callback for customising Tomcat's ProtocolHandler

[pas2al]

Introduce the new callback interface TomcatProtocolHandlerCustomizer
that can be used to customize the ProtocolHandler on a Tomcat Connector.

Fixes #15035

[mbhave]

@pas2al Thanks for the PR. I might be missing something but I don't see the new customizer being used anywhere in TomcatServletWebServerFactory and TomcatReactiveWebServerFactory. For example, the TomcatConnectorCustomizers get used here.

[pas2al]

Can you elaborate on that?

[mbhave]

Once the tomcatProtocolHandlerCustomizers have been set on the TomcatServletWebServerFactory and TomcatReactiveWebServerFactory, customize needs to be invoked for each one. This test will fail at the moment because the customize does not get called on the connector's protocol handler:

TomcatServletWebServerFactory factory = getFactory();
factory.addProtocolHandlerCustomizers(
        (TomcatProtocolHandlerCustomizer) protocolHandler -> protocolHandler.setThreadPriority(23));
Tomcat tomcat = getTomcat(factory);
Connector connector = ((TomcatWebServer) this.webServer).getServiceConnectors()
        .get(tomcat.getService())[0];
AbstractProtocol protocolHandler = (AbstractProtocol) connector.getProtocolHandler();
assertThat(protocolHandler.getThreadPriority()).isEqualTo(23);

[pas2al]

@mbhave Ok, that makes sense. I missed that, sorry! So should i call customize for each ProtocolHandlerCustomizer like this?

for (TomcatProtocolHandlerCustomizer customizer : this.tomcatProtocolHandlerCustomizers) {
	customizer.customize((AbstractProtocol<?>) connector.getProtocolHandler());
}

Would be the customizeConnector method a good place to do that (you pinned it in your comment above)?

I tried it this way and confirmed it with the test. I just want to clarify that i am on the right track.

[mbhave]

@pas2al Yup, customizeConnector would be a good place to do that. I also don't think we need to force the customizer to take a AbstractProtocol. We can just have the TomcatProtocolHandlerCustomizer customize a ProtocolHandler instead. It would look like this:

void customize(ProtocolHandler protocolHandler);

[pas2al]

Ok, thanks for the feedback! Regarding the ProtocolHandler. In #15035, the description suggested to make it customizable like this:

@Bean
public TomcatProtocolHandlerCustomizer<AbstractHttp11Protocol<?>> processorCacheCustomizer() {
	return (handler) -> handler.setProcessorCache(250);
}

So passing the type to the TomcatProtocolHandlerCustomizer is still the way to go or do we customize a ProtocolHandler? But then the Bean example above will not work.

[mbhave]

Sorry, you're right. I meant we could change the generic to expect a ProtocolHandler.

public interface TomcatProtocolHandlerCustomizer<T extends ProtocolHandler> {

That way we don't need to cast it to an AbstractProtocol when calling customize.

[pas2al]

Ok, should i type usages of the TomcatProtocolHandlerCustomizer like this <TomcatProtocolHandlerCustomizer<ProtocolHandler>>? For example for the usages in the TomcatServletWebServerFactory or do you suggest anything else?

[mbhave]

I think if you could update the PR with the change mentioned here and loop over the customizers to call customize for each one, we can take care of anything that's missing when merging.

[pas2al]

I updated the PR.

[mbhave]

@pas2al Thank you for making your first contribution to Spring Boot. This is now merged into master along with this polish commit.

[pas2al]

@mbhave Thank you very much for the opportunity and your support!