Problem mit JavaMail und Exchange Server 2007 - BAD Befehlsargument

In der Anwendung, an der ich arbeite, gibt es eine Funktion, die über IMAP mit JavaMail eine Verbindung zu einem Mailserver herstellt. Einer unserer Kunden hatte die folgende Stack-Trace:Problem mit JavaMail und Exchange Server 2007 - BAD Befehlsargument

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) ...

Nun, was es versuchte, ist folgendes zu tun:

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

Wo messages[i] ist ein javax.mail.Message.

Nun ist dieser Fehler bei keinem unserer Clients aufgetreten, die Exchange Server 2003 verwenden, und da dieser Client Exchange Server 2007 verwendet, nehme ich an, dass er etwas damit zu tun hat (Bug?). Ich habe auch sichergestellt, dass sie es auf den neuesten Service Pack und Rollup-Update aktualisiert (Service Pack 1 Update 8 zum Zeitpunkt der Erstellung) und die neueste JavaMail (1.4.2 zum Zeitpunkt der Erstellung) und es hatte keine Auswirkungen. Meine Frage ist, muss ich etwas warten auf Microsoft zu beheben? Gibt es eine Problemumgehung, die ich verwenden kann?

Für den Datensatz ist der Grund, warum ich das aktuelle Flag auf false festlegen, so dass die angegebene Nachricht nicht erneut in einem zweiten Durchlauf verarbeitet wird (d. H. Es verarbeitet nur aktuelle oder neue Nachrichten).

Quelle

2009-06-26 Avrom

Mein Lesen der API für Flags.Flag.RECENT zeigt an, dass es schreibgeschützt von einer Client-App ist. Die Ordnerimplementierung sollte es festlegen, wenn die "Nachricht für diesen Ordner neu ist". Wenn Sie also keine Ordnerimplementierung schreiben, sollten Sie dieses Flag nicht ändern.

Das lässt man sich wundern, warum Ihre anderen Kunden den Fehler nicht bekommen. Vielleicht wird es in einigen Fällen als NOOP behandelt? Vielleicht gibt es etwas Besonderes an diesem bestimmten Client-Ordner? Vielleicht ein freigegebener Ordner oder ein Ordner, zu dem der Benutzer Lesezugriff hat? Ich bin nicht dafür ausgerüstet, über die Geheimnisse des Exchange-Nachrichtenspeichers nachzudenken.

Quelle

2009-06-30 20:07:50

Ein anderer Client in Exchange Server 2007 hatte das gleiche Problem. Sie "lösten" das Problem selbst, indem sie das Postfach löschten und neu erstellten und es auf ein Upgrade-Problem von 2003 bis 2007 hinwiesen. Bei diesem anderen Client ist das Problem trotz der Neuerstellung des Postfachs weiterhin aufgetreten. Kein Kunde, der das Jahr 2003 noch nutzt, hat sich bereits beschwert. – Avrom

Wenn ich die Javadocs richtig verstanden habe, wenn ich den Mail-Ordner ordnungsgemäß schließe und zu einem späteren Zeitpunkt wieder öffne, sollte das aktuelle Flag für alle Nachrichten deaktiviert sein, die beim vorherigen Öffnen vorhanden waren. Wenn ja, sollte das meine Bedürfnisse erfüllen. – Avrom

@Avrom: Das wäre mein Verständnis. Schließen und erneutes Öffnen sollten alle neuen Nachrichten als RECENT markieren. Aber ist Ihre App die einzige, die auf die Ordner zugreift? Wenn nicht, vermute ich, dass Sie ein Problem haben, wenn eine andere App den Ordner öffnet/schließt. Ich bezweifle, dass Exchange (oder jeder IMAP-Server) ein RECENT-Flag nur für Ihre Anwendung beibehalten würde. Wenn es für Ihre Anwendung wichtig ist, zu wissen, welche Nachrichten verarbeitet werden, müssen Sie wahrscheinlich ein benutzerdefiniertes Flag für die Nachrichten festlegen. –

Problem mit JavaMail und Exchange Server 2007 - BAD Befehlsargument

Antwort

Verwandte Themen