Open jesse-gallagher opened 3 years ago
From 2020-06-22:
In investigating a bit, I think our main option is to register a factory with DataHandler.setDataContentHandlerFactory
that provides implementations of the handlers that don't rely on the conflicted com.sun.*
classes found in both the old and new Mail APIs. The down sides here are both the duplication of code and the fact that DataHandler
enforces that only one such factory is ever set - which could end up being an annoying bit of behavior in some cases.
I also tried registering a handler with META-INF/mailcap
, but I don't think we have any way to make our handler class name take precedence over the one in the API JAR itself.
From 2020-06-22:
It may also work to juggle classloaders somewhere, since the bit of code that loads the class by name uses the thread context class loader. However, since the stack that leads to this problem doesn't actually run through the API, it would have to be up to the app side to do so.
From 2021-05-03:
We could also potentially add a method to MimeWriter
to write to an OutputStream
and document this as the rationale for its existence.
This is presumably from picking up a provider that's present in the Notes JVM jvm/lib/ext directory.
This was observed in Notes 11.0.0 on macOS, but not on 11.0.1, so it may be a moot point. Still worth keeping an eye on for the short term, though.