james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Ivanov" <my...@surfeu.fi>
Subject Re: Threads in James: Re: Tomcat + James in a single jvm process
Date Wed, 05 Jun 2002 13:41:24 GMT
Hi, Serge

> smtp).  You add 2 properties to the
>javax.mail.Session properties, and

No, this is not correct. This article is good example of how to *hack* java
mail to make it SSL enabled but nothing more. I implemented one client (my
first version of TLSRemoteDelivery) using this article, but alas this
approach is not compatible with Avalon ideology at all.

> from fine tuning from years of experience dealing with what other mail
I have to think about that, because, honestly, this is my deep concern as
well. So far I am not ready to give answer for this your argument. But I
still stay for my points from my previous email.

> But ultimately, it's all about the code.  I'm happy to look over
> whatever you would like to submit

Did you have time to review my recent submission (SMTPServer-Handler)?

Andrei

PS could you please share more information about the problems you've
experienced with excalibur threads. How I can repeat those? This is *very*
critical for James based the solution I am working on.



----- Original Message -----
From: "Serge Knystautas" <sergek@lokitech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Wednesday, June 05, 2002 4:08 PM
Subject: Re: Threads in James: Re: Tomcat + James in a single jvm process


> 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=2
09.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>
>


--
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