james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Threads in James: Re: Tomcat + James in a single jvm process
Date Wed, 05 Jun 2002 13:08:29 GMT
Andrei Ivanov wrote:
> Hi,
> I was about to offer this, just wanted so that initiative is not going from
> me :-)
> 
>>We'd be pleased to accept your kind offer to contribute... ;-D
>>
> 
> So I have RemoteDelivery mailet which doesn't use JavaMail for transport,
> which uses excalibur threads and cornerstone socket factory (and of course
> support TLS and so on). It works very well ;-D
> Unfortunately I implemented it before I got a chance to look at JavaMail
> sources which were released recently. Now I see some ways to improve it.
> 
> Anyway before any further contributions from me I would like to hear from
> Serge about my improvements to SMTPServer-Handler submitted recently :-)
> 
> Andrei

Well, I'm not really enamored with refactoring working James code just 
because Avalon provides functionality XYZ.  I can understand the 
consistency argument.  However, I also have found the Avalon thread 
pooler to be less reliable than the quick and dirty approach used by 
RemoteDelivery (periodically I've had to restart James because the spool 
manager threads had all died/hung while I haven't seen this with remote 
delivery).

I would like to remove the JavaMail delivery dependency because JavaMail 
is not really a server-geared API.  That said, SMTP is an incredibly 
challenging API not because of its complexity, but because it's been 
around for so long and there are so many liberties other servers take 
with it.  The settings that RemoteDelivery passes to the Transport are 
from fine tuning from years of experience dealing with what other mail 
servers can stand to hear.  Introducing a whole new codebase can be 
extremely risky, because even if you can't deliver to 5% of the mail 
servers out there, you're going to hear about it (but probably not until 
a couple of weeks of bounces have been going on).

As for SSL transport delivery, I think that's a reason to stick with 
JavaMail actually... it's much more standard and well documented than 
moving to a custom SMTP implementation and Avalon sockets.  Here's a 
good article on the matter 
http://www.javaworld.com/javaworld/javatips/jw-javatip115.html?remote_addr=209.1.23.157&user_agent=Ultraseek/IDG.net

(this talks about securing other providers, but the same should work for 
smtp).  You add 2 properties to the javax.mail.Session properties, and 
boom, you've got SMTP w/SSL.  Doesn't seem like we need to refactor there.

But ultimately, it's all about the code.  I'm happy to look over 
whatever you would like to submit, and I'll let you know what I think. 
I just wanted to share some of my reservations going into this.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message