Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1114950

Summary: JavaMail- using wrong classloader when loading default providers
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jonáš Trantina <jtrantin>
Component: MailAssignee: jboss-set
Status: CLOSED EOL QA Contact: Michael Cada <mcada>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2.3, 6.2.4CC: pslavice
Target Milestone: ---   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-19 12:49:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproducer source code none

Description Jonáš Trantina 2014-07-01 10:25:20 UTC
Created attachment 913721 [details]
Reproducer source code

Description of problem:
When creating a javamail Session with provided custom Authenticator, class of this Auth. is used for loading /META-INF/javamail.default.providers and /META-INF/javamail.default.address.map resources. These resources located in the javamail jar will not be found when the Authenticator class uses different classloader (e.g. is supplied with user application).

However, this is not a big issue if user does not provide his own javamail.providers file, but if he does, he effectively bypasses the if section at line 907 causing only the specified providers to be loaded (the default providers are not loaded at all).

The code responsible is in javax.mail.Session#loadProviders(Class cl) at line 905:
  loadResource("/META-INF/javamail.default.providers", cl, loader);
and javax.mail.Session#loadAddressMap(Class cl) at line 1021:
  ladResource("/META-INF/javamail.default.address.map", cl, loader);

I don't think it makes sense to look for these defaults in the user application and not in the mail.jar, where they are located. Therefore, I would suggest changing the lines above to:
  loadResource("/META-INF/javamail.default.providers", this.getClass(), loader);
and
  loadResource("/META-INF/javamail.default.address.map", this.getClass(), loader);

I have built and tested it and it seems to solve the problem.


Version-Release number of selected component (if applicable):
mail-1.4.5-redhat-1.jar

Steps to Reproduce:
0. Build the reproducer attached- run "mvn clean package"
1. Deploy the reproducer
2. Go to http://localhost:8080/mail-reproducer/index.jsf
3. Click the button- this creates JavaMail session
4. In the log, observe that both resources were not found and defaults (from source code) are used.
5. Rename javamail.providersX to javamail.providers, build the reproducer go through steps 1. to 3. again.
6. Observe that only the specified dummy provider is registered and the defaults are not included.

Actual results:
Default providers are not loaded.

Expected results:
Default providers should be loaded at all times.

Comment 1 Martin Velas 2014-08-11 09:54:04 UTC
Issue is still valid for EAP 6.3.0.ER10. 

Note: I was not able to build the reproducer without adding further repositories into pom.xml:
    <repositories>
        <repository>
            <id>JBoss repository</id>
            <url>http://repository.jboss.org/nexus/content/groups/public/</url>
        </repository>
        <repository>
            <id>JBoss maven repository</id>
            <url>http://maven.repository.redhat.com/techpreview/all/</url>
        </repository>
    </repositories>

Comment 2 Tomaz Cerar 2014-11-07 16:10:50 UTC
Problem with proposed solution is that we would have to fork javamail codebase and maintain it ourselfs.