Open sbasegmez opened 3 months ago
Hmm, this may be very sticky indeed. Since RunJava stuff runs all in the same classpath pool, then the newer-era Jakarta Mail implementation will butt heads with the ancient one included in Domino.
The trouble is that Jakarta Mail is the closest to a standard that we can target for this sort of thing, but the presence of the old one in Domino makes it tough. It could be possible to provide an alternative fork of Jakarta Mail that doesn't reference the old class names for cases like this, but that'll take some investigation.
Could you try using this dependency instead of com.sun.mail:jakarta-mail?
<dependency>
<groupId>org.eclipse.angus</groupId>
<artifactId>jakarta.mail</artifactId>
<version>2.0.3</version>
</dependency>
You may also have to add an exclusion in your JNX dependency to exclude jakarta.mail:jakarta.mail-api, since Angus's jakarta.mail includes the API.
It requires Java 11, which is why JNX doesn't reference it yet, but it has the very-pleasant trait of them finally having renamed away from com.sun in the default mailcap file.
It's possible it will still run into trouble due to finding the mailcap file in the other JAR first, but it's worth a try. If this happens and you're not currently glomming everything together into one JAR, it could be worth trying that with maven-shade-plugin.
I couldn't try this. I gave up this path since I noticed that this was poisoning my dependencies in the OSGi part. It makes sense to take the Rust-based add-in path instead.
A class extending RunJavaAddin generates an exception about Jakarta.mail class.
The marked line throws the following stack trace:
I don't think we can find a solution for this problem, as it is systematic for the domino environment. But a workaround would be great.
The server is Domino Server 14.0.1. Using JNX version 1.40