Проблема с JavaMail и Exchange Server 2007 - аргумент команды BAD - PullRequest
Новая
       34

Проблема с JavaMail и Exchange Server 2007 - аргумент команды BAD

1 голос
/ 27 июня 2009

В приложении, над которым я работаю, есть функция, которая соединяется с почтовым сервером через IMAP с использованием JavaMail. У одного из наших клиентов была следующая трассировка стека: 

javax.mail.MessagingException: A13 BAD Command Argument Error. 11; 
nested exception is: 
com.sun.mail.iap.BadCommandException: A13 BAD Command Argument Error. 11 
at com.sun.mail.imap.IMAPMessage.setFlags(IMAPMessage.java:847) 
at javax.mail.Message.setFlag(Message.java:565) ...

Теперь, то, что он пытался сделать, это следующее: 

messages[i].setFlag(Flags.Flag.RECENT, false);

Где messages[i] является javax.mail.Message.

Теперь эта ошибка никогда не возникала ни у одного из наших клиентов, которые используют Exchange Server 2003, и, поскольку этот клиент использует Exchange Server 2007, я предполагаю, что он как-то связан с этим (ошибка?). Я также позаботился о том, чтобы они обновили его до последнего пакета обновления и накопительного обновления (пакет обновления 1 с обновлением 8 на момент написания этой статьи) и до последней версии JavaMail (1.4.2 на момент написания этой статьи), и это никак не повлияло. У меня вопрос, это то, что я должен ждать, пока Microsoft исправит? Есть ли обходной путь, который я могу использовать?

Что касается записи, то причина, по которой я устанавливаю недавний флаг в значение false, заключается в том, что данное сообщение больше не будет обрабатываться во втором проходе (т. Е. Оно обрабатывает только последние или новые сообщения).

1 Ответ

1 голос
/ 01 июля 2009

Мое чтение API для Flags.Flag.RECENT указывает, что оно доступно только для чтения из клиентского приложения. Реализация папки должна устанавливать его, когда «сообщение является новым для этой папки». Поэтому, если вы не пишете реализацию папки, вам не следует изменять этот флаг.

Это заставляет задуматься, почему другие ваши клиенты не получают ошибку. Возможно, в некоторых случаях это рассматривается как NOOP? Возможно, есть что-то особенное в этой конкретной клиентской папке? Возможно, общая папка или папка, к которой у пользователя есть права на чтение? Я не приспособлен для размышлений над тайнами хранилища сообщений Exchange.

...