Ошибка класса DCH с JavaMail

добавьте их перед отправкой сообщения:

MailcapCommandMap mc = (MailcapCommandMap) CommandMap.getDefaultCommandMap();
        mc.addMailcap("text/html;; x-java-content-handler=com.sun.mail.handlers.text_html");
        mc.addMailcap("text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml");
        mc.addMailcap("text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain");
        mc.addMailcap("multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed");
        mc.addMailcap("message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822");
        CommandMap.setDefaultCommandMap(mc);

У меня проблема в моем приложении для Android, и он работает.

в моем случае я смог решить эту проблему, добавив это до отправить():

Thread.currentThread().setContextClassLoader( getClass().getClassLoader() );

Это было предложено в связанном блоге, поэтому, если вы хотите узнать больше деталей, прочитайте его. Спасибо Джерри ГУ за то, что он связал его здесь и оригинального блоггера.

URL:http://blog.hpxn.net/2009/12/02/tomcat-java-6-and-javamail-cant-load-dch/

вероятность высока, что если вы работаете на сервере KARAF(OSGI), вышеуказанные предложения будет трудно реализовать, поскольку у Karaf нет класса запуска или пути к классу загрузки.

Я нашел эту активацию.конфликт jar создал эту проблему .

{FUSEESB_HOME Or ServiceMIX_HOME}/etc/jre.properties was loading activation.jar .

после комментария все было гладко.

см. ссылке ниже.

хотя я хотел бы узнать больше о деталях, почему это проблема, и что этот параметр-Xbootclasspath делает для исправления проблемы.

это связано с деревом classloader. Напомним, что дочерним загрузчикам классов разрешено искать классы в Родительском загрузчике классов, но не наоборот. В вашем примере программы дерево classloader выглядит следующим образом:

Running under JDK6, JDK7, and JDK8
+---Boot ClassLoader--+
| java.util.logging.* |
| javax.activation .* |
+---------------------+
          ^
          |
+-----System ClassLoader------+
| javax.mail.*                |
| com.sun.mail.handlers.*     |
| com.sun.mail.util.logging.* |
+-----------------------------+

когда LogManager$Cleaner крючок выключения бежит (JDK6+) context classloader вынужден загрузки загрузчиком что не может найти com.sun.mail.handlers.text_plain класс, потому что он находится в дочернем загрузчике классов. Из-за этого, модификации MailcapCommandMap для включения имен классов mailcap не исправит проблему. Когда вы используете -Xbootclasspath опция вы размещаете все соответствующие классы в загрузчике классов загрузки, который виден LogManager$Cleaner. Однако не изменяйте свою систему для использования -Xbootclasspath исправить это вопрос.

неполное исправить применяется к JavaMail 1.4.7, чтобы установить загрузчик класса контекста в загрузчик класса, который загрузил MailHandler во время закрытия. Этот предполагается, что загрузчик классов, который загрузил MailHandler должны быть в состоянии найти код активации.

если вы не можете обновить до более новой версии JavaMail, то вы должны применить один из следующих обходных путей:

1. очистите или закройте MailHandler перед запуском очистителя.
2. очистите все обработчики перед запуском очистителя (т. е. веб-приложение не развертывается). Вы должны синхронизировать на LogManager и собрать все обработчики от каждого регистратора. Промывать все обработчики вне синхронизированного блока.
3. расширьте MailHandler и переопределите close, чтобы установить и восстановить загрузчик классов контекста, если загрузчик классов контекста равен null.
4. установите новый LogManager и переопределите reset для установки и восстановления загрузчика классов контекста, если загрузчик классов контекста равен null.
5. установите форматер темы, чтобы установить загрузчик классов контекста, если работает очиститель.
6. установите уровень нажима на ALL или установите емкость в 1, чтобы отправить электронное письмо для каждой записи журнала и получить спам.
7. запустите версию Java с исправлением с помощью RFE JDK-8025251.

основная проблема в том, что LogManager$Cleaner заставляет загрузчик классов контекста равняться null перед вызовом close на каждые Handler зарегистрированы с LogManager. Лучшим выбором для LogManager было бы установить context classloader в загрузчик класса обработчика перед вызовом close, тогда в конце концов обработчики закрыты установите загрузчик класса контекста в значение null. Это все еще можно было обмануть обработчиками гнезд, но, по крайней мере, это исправило бы общий случай. Это было подано как RFE JDK-8025251 "logmanager cleaner должен использовать обработчик classloader во время закрытия".

Я столкнулся с этой проблемой сегодня, и это было связано с загрузчиком класса потока.

Если вы делаете sysout на: com.солнце.почта.дрессировщики.multipart_mixed.класс.getClassLoader()

Это может быть не то же самое, что загрузчик классов текущего потока: Нитка.currentThread().getContextClassLoader()

Я смог прийти к этому выводу, добавив следующий arg: -Djavax.активация.debug=true

после добавления этого arg я увидел, что он не смог чтобы загрузить обработчик содержимого данных (DCH) для multipart_mixed.класс.

Как вы решаете свои проблемы с загрузчиком классов, зависит от вас,но это должно заставить вас начать.

для всех, имеющих это сообщение об ошибке выше, оказалось, что в моем случае данные аутентификации были пустыми, это было связано с тем, что я отключил аутентификацию почтового сервера, мне больше не нужны имя пользователя и пароль, но пустые значения были каким-то образом проанализированы и создали отсутствующую ошибку аутентификации, которая не была поймана хорошо в Mail 1.4.0, обновление до Почты 1.4.7 и удаление двух параметров-записей ниже проблема решена.

<appender name="ALARM_MAIL" class="my.utils.SMTPAppender">
  <!-- remove this line: <param name="SMTPUsername" value=""/> -->
  <!-- remove this line: <param name="SMTPPassword" value=""/> -->
  ...