Support tomcat-coyote-ffm for native ssl with embedded Tomcat

[philsttr]

Enhancement Request

I would like for Spring Boot to provide first-class support for autoconfiguring tomcat-coyote-ffm for native ssl without using APR or tomcat-native.

Background

Setting up APR and tomcat-native is somewhat complicated, and difficult to "get right".

Tomcat recently introduced a new tomcat-coyote-ffm module, which allows using native ssl without requiring APR or tomcat-native. Internally tomcat-coyote-ffm uses Java's Foreign Function & Memory API to directly call libssl.

Spring Boot currently has first-class autoconfiguration support for native ssl using APR and tomcat-native, but does not offer first-class support for tomcat-coyote-ffm.

Currently, it is possible to enable tomcat-coyote-ffm in a Spring Boot app with embedded Tomcat, but it is not intuitive or documented anywhere.

It would be great if Spring Boot provided first-class support for using tomcat-coyote-ffm.

The current situation

Enabling tomcat-coyote-ffm in a Spring Boot app with embedded Tomcat today is not intuitive.

The typical way to enable tomcat-coyote-ffm module is by registering a OpenSSLLifecycleListener lifecycle listener on Tomcat's Server object (as described in the tomcat docs).

Spring Boot does not provide direct access to embedded Tomcat's Server object, so subclassing TomcatServletWebServerFactory is required.

public class FfmOpenSslTomcatServletWebServerFactory extends TomcatServletWebServerFactory {

	@Override
	protected Tomcat createTomcat() {
		Tomcat tomcat = super.createTomcat();
		tomcat.getServer().addLifecycleListener(new OpenSSLLifecycleListener());
		return tomcat;
	}
}

Then, declare the FfmOpenSslTomcatServletWebServerFactory bean:

@Configuration(proxyBeanMethods = false)
public class TomcatFfmOpenSslConfig {

	@Bean
	public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
		return new FfmOpenSslTomcatServletWebServerFactory();
	}
}

And also add a dependency on tomcat-coyote-ffm, while excluding the non-embedded Tomcat transitive dependencies (side note: this Tomcat feature request should help this situation).

		<!--
			tomcat-coyote-ffm provides the FFM/panama-based OpenSSL integration
			(org.apache.tomcat.util.net.openssl.panama.*) used by
			org.apache.catalina.core.OpenSSLLifecycleListener (which lives in
			tomcat-embed-core). This replaces tomcat-native / APR for OpenSSL.
			Its transitive deps (tomcat-coyote / tomcat-juli / tomcat-util) are
			excluded because tomcat-embed-core already ships those classes under
			the same FQCNs; keeping both would put duplicate classes on the
			classpath.
		-->
		<dependency>
			<groupId>org.apache.tomcat</groupId>
			<artifactId>tomcat-coyote-ffm</artifactId>
			<version>${tomcat.version}</version>
			<exclusions>
				<exclusion>
					<groupId>org.apache.tomcat</groupId>
					<artifactId>tomcat-coyote</artifactId>
				</exclusion>
				<exclusion>
					<groupId>org.apache.tomcat</groupId>
					<artifactId>tomcat-juli</artifactId>
				</exclusion>
				<exclusion>
					<groupId>org.apache.tomcat</groupId>
					<artifactId>tomcat-util</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

Desired solution

I'd like Spring Boot to be able to auto-configure tomcat-coyote-ffm if it is available on the classpath. Specifically, if org.apache.tomcat.util.net.openssl.panama.OpenSSLLibrary is on the classpath, then add a OpenSSLLifecycleListener to Tomcat's Server object.

Perhaps add a tomcat.server.use-ffm property, parallel to tomcat.server.use-apr.

Alternatively, if direct support for tomcat-coyote-ffm cannot be provided... at least provide the ability to register a lifecycle listener on Tomcat's Server object, so that subclassing TomcatServletWebServerFactory is not required. (Note that it is currently possible to access the Context object to add a lifecycle listener, but not the Server object).

[Will-thom]

Hi @philsttr

Thanks for the detailed proposal — this makes a lot of sense, especially considering the complexity around APR/tomcat-native setup.

I have a question regarding the autoconfiguration approach and long-term supportability:

Since tomcat-coyote-ffm relies on the Foreign Function & Memory API and relatively recent Tomcat internals, are there concerns on the Spring Boot side about:

• stability/maturity of the FFM-based integration compared to APR
• compatibility across different Java versions and Tomcat upgrades
• or potential constraints in supporting it as a first-class auto-configuration feature

In other words, is the lack of support today mainly a gap in implementation, or a deliberate decision due to these trade-offs?

Also, would exposing a more general hook to customize the Tomcat Server (e.g., lifecycle listeners) be more aligned with Spring Boot’s design than adding a dedicated use-ffm property?

Curious to understand how you see this fitting into Boot’s autoconfiguration philosophy.

[wilkinsona]

I've opened #50259 to add a mechanism for general purpose customization of the Server instance. I'm not sure that we should rush to add tomcat-coyote-ffm support, not at least until we see some more demand for it. Ideally, it'd also like to see the need for the excludes go away as that would be a strong indication that it's packaged for and intended to be used in the embedded case.

[philsttr]

stability/maturity of the FFM-based integration compared to APR

AFAIK Tomcat's FFM-integration is production ready. It has been available since 2024 in Tomcat 9, 10, and 11. @markt-asf even recommended it as a potential solution to other APR struggles.

compatibility across different Java versions and Tomcat upgrades

Regarding Java, the ffm module is only compatible with Java 22+, but I think that can be easily handled.

Regarding Tomcat, given that the ffm module has been available in Tomcat 9, 10, and 11 since 2024, I don't think that is much of a concern either. Especially since Spring Boot manages the version of Tomcat.

or potential constraints in supporting it as a first-class auto-configuration feature.

the only thing I can think of as a constraint is the current need to exclude transitive dependencies (which goes away after the tomcat feature request is implemented)

In other words, is the lack of support today mainly a gap in implementation, or a deliberate decision due to these trade-offs?

I see it mainly as a gap in implementation

Also, would exposing a more general hook to customize the Tomcat Server (e.g., lifecycle listeners) be more aligned with Spring Boot’s design than adding a dedicated use-ffm property?

Since Spring Boot currently has a use-apr property, I think having a use-ffm property would be natural and expected by users.

I've opened #50259 to add a mechanism for general purpose customization of the Server instance.

Thanks!

it'd also like to see the need for the excludes go away as that would be a strong indication that it's packaged for and intended to be used in the embedded case.

Totally agree with that.

---

To summarize... I think Tomcat's FFM integration with openssl will be the preferred option to enable openssl in the years to come, given its simplicity. I'd hate for Spring Boot to be stuck in the past, only supporting APR, which is much more complex for users to setup. Additionally, if you ever wanted to deprecate APR support, it would be nice to offer a convenient solution to which users can migrate.

I agree that the need for transitive dependency exclusions is a barrier to a clean implementation in Spring Boot. Hopefully the tomcat feature request can be addressed soon.

The following approach seems best to me:

1. Implement Provide a callback for customizing Tomcat's Server #50259 for now
2. Wait for Tomcat bz69987 to be implemented
3. Add first-class support in Spring Boot (this issue) (e.g. use-ffm property and dependency management for tomcat's ffm module, without exclusions)