James 2.3.0 alpha 2 show stoppers (Was: [jira] Resolved: (JAMES-477))

[Stefano Bagnara <ap...@bago.org>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org