A similar problem appeared when running a Java 8 S/MIME parsing code on Java 12.
Relevant (missing) DCH was for a custom MIME type message/disposition-notification
.
Unlike in old Java's native javax.activation.ObjectDataContentHandler
,
the external javax.activation:activation
library for Java 9+, does not seem to tolerate "unknown" MIME types;
earlier, multipart "parts" with such custom content-types (not found in mailcap
meta-files)
were still consumed if they contained byte[]
or String
content - but not anymore.
// old native
public void writeTo(Object obj, String mimeType, OutputStream os) throws IOException {
if (this.dch != null) {
this.dch.writeTo(obj, mimeType, os);
} else if (obj instanceof byte[]) {
os.write((byte[])((byte[])obj));
} else {
if (!(obj instanceof String)) {
throw new UnsupportedDataTypeException("no object DCH for MIME type " + this.mimeType);
}
OutputStreamWriter osw = new OutputStreamWriter(os);
osw.write((String)obj);
osw.flush();
}
}
// new javax.activation:activation
public void writeTo(Object obj, String mimeType, OutputStream os)
throws IOException {
if (dch != null)
dch.writeTo(obj, mimeType, os);
else
throw new UnsupportedDataTypeException(
"no object DCH for MIME type " + this.mimeType);
}
Solution was to define an entry for message/disposition-notification
(it can be safely interpreted as text)
in a mailcap
file; technically similar to @Som's answer, but we all love no-code solutions, right?
message/disposition-notification;;x-java-content-handler=com.sun.mail.handlers.text_plain
and bundle it into the JAR (classpath); e.g. with Maven:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>META-INF/mailcap</include>
</includes>
</resource>
</resources>
</build>
Also noteworthy: setting a -Djavax.activation.debug=true
system property on the JVM,
greatly helps in tracing issues related to such mailcap
loading, handling, fallbacks etc.