-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to Angus Mail 2.0.3 #6068
Conversation
} | ||
// 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
Rationale
Angus Mail is the active development project, successor to Jakarta Mail
Related Pull Requests