I agree with your comment. jakarta.mail is indeed not well-designed for this use case.
I understand your concerns about these requirements, and I'm open to exploring alternative approaches.

I think the delegating Transport implementation can be used programmatically. Taking your example code, something like the following, assuming some changes to MicrometerSMTPTransport including renaming to MicrometerInstrumentedTransport:

        Session session = Session.getInstance(smtpProperties);

        // create a new message
        MimeMessage message = createMessage(session, messageDetails);

        // send the message
        try (Transport transport = new MicrometerInstrumentedTransport(session, session.getTransport(), registry)) {
            transport.connect("smtp.example.com", 465, "user", "password");
            transport.sendMessage(message, message.getAllRecipients());
        }

Alternatively, maybe wrapping the Session so it returns Micrometer wrapped Transports is another option. I'm not sure what offers the best usability for most common usage of the Jakarta Mail API.

Session session = MicrometerInstrumentedSession.wrap(Session.getInstance(smtpProperties), registry);

I believe it would be a better solution to use a constructor to inject ObservationRegistry and custom conventions. However, this would require the framework to allow decorating the Transport class.

@bclozel, are you considering adding a feature to the JavaMailSender that would allow us to decorate the Transport class?

It may already be possible since getTransport is protected on JavaMailSenderImpl with the following note:

Can be overridden in subclasses, for example, to return a mock Transport object.

To expand on my previous comment, perhaps it would look something like:

@Bean
JavaMailSender instrumentedJavaMailSender(ObservationRegistry registry) {
    return new JavaMailSenderImpl() {
        @Override
        protected Transport getTransport(Session session) throws NoSuchProviderException {
            return new MicrometerInstrumentedTransport(session, super.getTransport(session), registry);
        }
    };
}

I'm not sure we should introduce a mandatory dependency for micrometer-observation in spring-context-support just for this use case. We can consider exposing a subclass and make it optional. On the other hand, the code snippet that @shakuzen shared seems fine for a Spring Boot auto-configuration as well.

I've pushed changes so we're compiling against and testing on Jakarta 9 in the micrometer-jakarta9 module, and I've added a Jakarta 10 "sample" module for testing the instrumentation on Jakarta 10 dependencies. I've also polished things, and I think we're good to merge. We should follow-up with adding documentation for this instrumentation.

Oo very clever solution for Jakarta 10.

Should we document something? I haven't found any documentation on the built-in micrometer instrumentation and how to use it.

Documentation for instrumentation we provide is under this section. We don't have anything for the Jakarta module currently, but we could add a page and document the Jakarta Mail instrumentation there. It doesn't need to be done in this PR. We can follow-up with it once we merge this so we know there aren't any more changes to be made.

When do you plan to merge the pull request? So that I can schedule a PR on Spring Boot to autoconfigure this.

I've asked @jonatan-ivanov to review. The main concern is whether we've got the right default convention, since once we go GA, we would break compatibility if we change it. For that reason, we may hold off until Micrometer 1.16 to get feedback on this from M1. On the other hand, I'm not sure how much feedback we can expect on this if we held it until 1.16 since it was never requested before. In that sense, there may be no issue to merge it for 1.15.0-RC1.

Hi, just a ping to let you know that I'm not able to work on this PR this week.