Custom mail providers distributed under META-INF/javamail.properties are no longer loaded with Jakarta Mail 2.1.5

[yersan]

Describe the bug
Jakarta Mail 2.1.5 is not backward compatible with how custom providers distributed by the application are loaded. Providers declared under META-INF/javamail.properties are no longer loaded; users are now forced to rename the file to META-INF/jakarta.properties instead. I understand it as a backward compatibility issue.

To Reproduce
See reproducer attached to this issue, it is just a test case that loads the session and tries to assert that the custom providers declared on META-INF/javamail.properties are available from Session.getProviders()

mail-reproducer.zip

Expected behavior
Custom providers distributed via META-INF/javamail.properties are loaded.

Additional context
This issue was introduced via here. As soon as the providers coming from the META-INF/jakarta.properties that are available on the classloader via Angus Mail are processed, the for loop is broken and the code skips processing other possible providers distributed by the application via META-INF/javamail.properties

[bstansberry]

Actually I think the issue is here:

223c350#diff-5cbee3986400643f15064c1c111133ea02d864c75ed3ad777d192159f8f6ea89L1268

Before this change, for a given name all resources with that name would be found and processed. The break introduced at that line stops that and now only the first resource with the name will be processed. The angus-mail-2.0.4.jar and angus-mail-2.0.5.jar files both have a META-INF/javamail.providers file, so if it and an application containing a META-INF/javamail.providers are visible to the TCCL, only one will be processed.

[yersan]

I agree, but notice that the break you pointed out was removed in Jakarta Mail 2.1.5, whereas it is present in 2.1.4. That could be an explanation for why the WildFly tessuite is still failing with Jakarta 2.1.4 when my reproducer attached to this issue passes with such a Jakarta Mail version. Basically, it depends on the order in which those resources are loaded.

In any case, both seem problematic for loading the providers by the application code. The one I pointed out on Jakarta Mail 2.1.5 will skip the processing of META-INF/javamail.providers as soon as META-INF/jakarta.providers are processed, which breaks the backward compatibility. The one you pointed out in Jakarta Mail 2.1.4 skips any additional META-INF/javamail.providers or META-INF/jakarta.providers found on the classpath, and, if the ones coming from Angus Mail are processed first, the ones coming from the application code won't be processed at all.

[jbescos]

Hi, this is originally the issue related to this topic: eclipse-ee4j/angus-mail#151

If it finds any jakarta.providers, it will not process javamail.providers, but it is true that in the moment you introduce jakarta.providers, any existing app having javamail.providers will not be loaded. There is a note in compatibility here about this.

There are several ways to address this:

• Depend on org.eclipse.angus:angus-mail:2.0.3. This one does not introduce the new jakartified files, so the old javamail.providers will be loaded. You don't need to wait for a fix in this option.
• We can load both files (jakarta.providers and javamail.providers). There will be some duplicates but we can deal with it.
• Load first javamail.providers. Not sure this is a good solution, because 2 different apps running in same classpath, one having javamail.providers and the other jakarta.providers, will exclude the second one.

[yersan]

Thanks @jbescos for the suggestions and for your time looking at this.

Upgrading Jakarta Mail to the latest while keeping Angus Mail under 2.0.3 works for this user case, although users cannot continue consuming bug fixes from Angus Mail 2.0.x without breaking the compatibility of their applications.

So, in my opinion, ideally, a solution where jakarta.providers and javamail.providers can coexist together would be nice for Jakarta Mail 2.1.x and Angus Mail 2.0.x combinations, leaving the breaking change for future minor/major versions.