Hmmm... in our application there's not necessarily a 1:1 mapping between the user session and the IMAP session (the IMAP client is only a part of our application); this could be a problem, if I understand you correctly.
I should double check it, but I 'm fairly sure that when a message is 'deleted' through the related application command, the embedded IMAP client marks and expunges it right away. And this can't be (easily at least) changed as per application architecture.
But I don't understand why this should be wrong: when I say that 'I edit the draft' I mean that the whole draft data (subject, body, attachments, ...) is loaded in application memory / structures, so that no information regarding the original message should remain linked to the new message and in fact anything about it will be anymore needed.
Or, otherwise stated, is there a way to completely 'detach' an IMAPMessage from its server-related message, so that any connection or reference doesn't exist anymore?
Thank you
M. R.
>________________________________
> Da: Bill Shannon <bill.shannon_at_oracle.com>
>A: xoot123_at_yahoo.it
>Cc: "users_at_javamail.java.net" <users_at_javamail.java.net>
>Inviato: Marted́ 7 Gennaio 2014 20:08
>Oggetto: Re: got a MessagingException -> parse error: invalid message sequence number
>
>
>
>Marking the message as deleted should not cause this problem unless some application expunges the message. Assuming your application isn't expunging the message before it's done with it, you need to consider what you expect to happen if another client expunges the message while you're using it. You might not want to mark the message as deleted until after you've saved the updated draft of the message.
>
>xoot123_at_yahoo.it wrote on 01/07/14 08:14:
>Hello,
>>I'm getting a javax.mail.MessagingException: A258 BAD parse error: invalid message sequence number: 24.
>>
>>I found that one possible execution path in our code
that leads to this exception is when I edit a draft with
attachments, delete the original draft, and then save
the edited draft (so that the original draft doesn't
exist anymore, but I have all the informations about it
in our application composition pane).
>>This only happens with drafts with attachments, it seems
that a reference to the original message number is
cached by JavaMail, despite the fact that the server
supports UIDs - and IMHO the original message isn't
needed anymore).
>>I have no idea if this is a bug, but if I do the same
steps with i.e. Thunderbird, no error occurs and the
edited draft is correctly saved.
>>
>>As the application I'm working on is very big, I can't
provide a small example, nor I can ensure this is our
own code fault.
>>I'm writing here in the hope that you'll be able to tell
me whether this is a bug or not, so I can narrow down
the possible causes (there's another source of that
exception in our code that I'm not yet able to
replicate).
>>
>>
>>
>>Thanks in advance.
>>
>>M. R.
>>
>
>
>