spring-boot
spring-boot copied to clipboard
spring-projects
Add mail sender support for spring-boot-testcontainers
Mail catcher is good solution to test email sending by SMTP, such as:
- https://mailcatcher.me/
- https://github.com/linux-china/mail-catcher
- https://github.com/maildev/maildev
- https://github.com/mailhog/MailHog
It will be good to add MailConnectionDetails support to make email sending test easy with mail catcher container.
We could update the auto-configuration to add MailConnectionDetails but I'm not sure how much we can do beyond that. As the list above shows, there are a variety of options for running an SMTP server. In terms of official Docker images for the above, there are:
- mailcatcher 1M+ pulls
- mail-catcher 404 pulls
- maildev 10M+ pulls
- MailHog 100M+ pulls
How the SMTP server is configured differs from image to image so I don't think we can offer a general purpose implementation for getting connection details from a container. MailHog appears to be the most popular, so perhaps that's the place to start? It would feel a little odd to have MailConnectionDetails and only have a properties-based implementation.
MailHog is good for me. All these mail catchers, they almost use 1025 as SMTP port, and I think we just use 1025 as exposed port for spring.mail.port.
The port should be fine. It's username and password that are more complicated. For example, maildev uses MAILDEV_OUTGOING_USER and MAILDEV_OUTGOING_PASS environment variables to configure the credentials for sending mail. These are easy for us to extract from the container and use in the connection details. On the other hand, MailHog seems to use a file which would be much harder to deal with unless we only supported the defaults.
@wilkinsona, is it possible to introduce org.springframework.boot.properties.xxxx labels, and these labels will be added ad Spring Boot properties. Example as following:
services:
mail:
image: "maildev/maildev"
ports:
- '1025'
labels:
org.springframework.boot.properties.spring.mail.host = "${container.getHost()}"
org.springframework.boot.properties.spring.mail.port = "${container.getMappedPort(1025)}"
org.springframework.boot.properties.spring.mail.username = demo
Value cloud be a SpEL, and container is the variable of GenericContainer or sub GenericContainer.
This way is still ok for other containers, such as NATS, Apache Pulsar etc.
It would feel a little odd to have MailConnectionDetails and only have a properties-based implementation.
Given ConnectionDetails is the entrypoint to do this, it wouldn't be that odd. Doing that, will allow to users create libraries with specific ConnectionDetailsFactory where there are more than one image or not an official image to choose such as mail and activemq. One example is RedisContainerConnectionsDetails, currently only supports standalone but there are images where cluster can be enabled and it's totally fine if spring boot doesn't provide RedisClusterConnectionDetailsFactory but the infrastructure is already there to do it for third-parties.
This is probably related.
For cases like this one and probably #35080 https://github.com/spring-projects/spring-boot/commit/26566d4a30233bb002449a2c0d7a8ffc84d3438e would fix it
this would be a wonderful feature, however, I am not sure how much is MailHog maintained
edit: https://github.com/axllent/mailpit This seems to be an actively maintained project
