-
Bug
-
Resolution: Fixed
-
P3
-
alpha
-
None
-
1.0fcs
-
sparc
-
solaris_2.5.1
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2018326 | alpha | J. Duke | P3 | Closed | Fixed | alpha |
I have the following in my mailcap file:
multipart/alternative;; x-java-view=sunw.bean.mail.msgviewer.display.Alternative
multipart/*;; x-java-view=sunw.bean.mail.msgviewer.display.MultipartViewer
multipart/alternative;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed
multipart/*;;x-java-content-handler=com.sun.mail.handlers.multipart_mixed
The viewers are differentiated correctly. If I don't specifically have a
multipart/alternative entry for the content handlers though, I don't get the
multipart/* content handler invoked. The result is that instead of getting back
a Multipart object I get back a ByteArrayInputStream.
I shouldn't have to add the multipart/alternative entry. The multipart/* entry
should be sufficient.
I'm using the "latest" source.
multipart/alternative;; x-java-view=sunw.bean.mail.msgviewer.display.Alternative
multipart/*;; x-java-view=sunw.bean.mail.msgviewer.display.MultipartViewer
multipart/alternative;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed
multipart/*;;x-java-content-handler=com.sun.mail.handlers.multipart_mixed
The viewers are differentiated correctly. If I don't specifically have a
multipart/alternative entry for the content handlers though, I don't get the
multipart/* content handler invoked. The result is that instead of getting back
a Multipart object I get back a ByteArrayInputStream.
I shouldn't have to add the multipart/alternative entry. The multipart/* entry
should be sufficient.
I'm using the "latest" source.
- backported by
-
JDK-2018326 shouldn't need to override wildcard entries in mailcap
-
- Closed
-