Am Samstag, den 15.04.2006, 19:43 +0200 schrieb Stefano Bagnara: > Norman Maurer wrote: > > I add some logs.. maybe we found something.. I also thought the problem > > is related to the message sise. > > thank you! > No problems. Now i just need a message which throw this exception. Is it possible to move the message again in the spool with something like:
insert into spool values select * from deadletter; ? > > 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). > I see that like you.. no conversion should be the way to go. > 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. > Good to know.. > Stefano > > PS: I probably should add this quick overviews as comments to the > respective JIRA issues. > Yes that whould be nice. > > 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] > > !EXCUBATOR:1,4441313637021261311631! bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
