Norman Maurer wrote:
I add some logs.. maybe we found something.. I also thought the problem
is related to the message sise.
thank you!
Can you explain what the other to problems are.. im just intressted.
the 7bit/8bit problem (I consider it part of JAMES-419) is the following:
Javamail, if 8bitmime is enabled, automatically convert 7bit messages to
8bit. Furthermore, if the remote server does not support 8BITMIME esmtp
extension automatically convert an 8bit message to 7bit (convertTo7Bit
in RemoteDelivery). Both this procedures do not work when the
MimeMessage is created from an InputStream (actually the message header
is changed but the body not, resulting in badly encoded messages).
The problem is related to this bug.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403733
We should add a "setContent(getContent())" after each operation
involving headers. The conversion to 7bit is in our code so this should
be easy, but the conversion to 8bit is in the SMTPTransport of javamail
and we should write a workaround to avoid the conversion or to make it
work. (I think we should avoid the conversion, and keep the current
transfer encoding: when the message is 7bit and read from a stream it
does not make sense to parse it only to send it using 8bit).
The JAMES-474 was the result of an optimisation that shared the
MimeMessageSource between multiple MimeMessages when cloning
MimeMessageWrappers. MimeMessageSource lifecycle is related to the
container MimeMessageWrapper so this would not work. BTW JAMES-474 is no
more a showstopper because I fixed it removing the sharing of the
source. I plan to work more on the
MimeMessageCopyOnWriteProxy/MimeMessageWrapper/MimeMessageSource
handling to simplify the code (merge the first 2, change
MimeMessageSource to provide SharedInputStreams), so the optimization
issue could be ignored by now.
Stefano
PS: I probably should add this quick overviews as comments to the
respective JIRA issues.
Am Samstag, den 15.04.2006, 17:14 +0200 schrieb Stefano Bagnara:
For JAMES-474 and JAMES-419 I already know what the problem is, and I
left them open because I would like to find a workaround or another
clean solution to not disable the 2 features/optimizations.
For JAMES-466 maybe the problem is related to the message size: the main
difference between the old code and the new one is that the new one have
to know the exact message stream size before writing it to db and when
the size is incorrect the exception is the one you reported. It could
also be a synchronization issue, or maybe some random but in the
connector/J streaming code. Can you add a try/catch to the
JDBCMailRepository.store method and log as much as you can about the
message being processed and the calculated size?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
