Skip to content

Upgrade to Angus Mail 2.0.3 - #6068

Merged
labkey-adam merged 4 commits into
developfrom
fb_angus_mail
Nov 20, 2024
Merged

Upgrade to Angus Mail 2.0.3#6068
labkey-adam merged 4 commits into
developfrom
fb_angus_mail

Conversation

@labkey-adam

Copy link
Copy Markdown
Contributor

Rationale

Angus Mail is the active development project, successor to Jakarta Mail

Related Pull Requests

}
}
// I couldn't get this to work once I switched to Angus Mail; kept getting this exception:
// java.util.ServiceConfigurationError: jakarta.mail.util.StreamProvider: org.eclipse.angus.mail.util.MailStreamProvider not a subtype

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it not finding MailStreamProvider or is it, in fact, not a subtype? If it seems like it is a subtype, perhaps there's some kind of classpath problem, but is this needed? Will it be checking something different from the if (properties.isEmpty()) block above?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to be finding MailStreamProvider which is a subtype. So yes, I agree it's likely a classpath problem. I tried quite a few combinations of Angus Mail + Jakarta Mail API + Angus Activation + Jakarta Activation API in both embedded and our API (none in embedded, all in both, etc.) to no avail. The new approach avoids JNDI and Tomcat's involvement, which seems to be an important difference and works as expected. As a non-trivial upgrade, it seemed best to get a working combination committed and tested. We can certainly revisit the JNDI approach in this or a follow-on PR.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I struggled with similar problems when migrating to Tomcat 10. They stemmed from having copies of the classes loaded by different class loaders, as you're both suspecting here. The error messages were frustrating because all the talk about is class names, which always looked correct.

If we're not relying on JNDI to wire things up, don't we need to handle all of the properties we propagate here?

https://github.com/LabKey/server/blob/93839d04e95a8f377f034b7a7094bf9e5ad9d437/server/embedded/src/org/labkey/embedded/LabKeyTomcatServletWebServerFactory.java#L379

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the new code populates all the same properties that the old code did

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the new code populates all the same properties that the old code did

Looks like you're right. I hadn't read enough of the adjacent, untouched code.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a first time for everything, I guess...

@labkey-adamlabkey-adam linked an issue Nov 19, 2024 that may be closed by this pull request
6 tasks
@labkey-adam
labkey-adam merged commit 5039f1b into developNov 20, 2024
@labkey-adam
labkey-adam deleted the fb_angus_mail branch November 20, 2024 17:45
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[LabKey CI] Upgrade Jakarta Mail --> Angus Mail

3 participants

@labkey-adam@labkey-jeckels@labkey-susanh