Precisely the reason that I thought of using the SMTP dialog handler from JAMES - I don't want to shoot anyone.Opening up an API for any Tom, Dick, or Harry to plug in an SMTP interceptor is roughly the equivalent of giving a six year old a loaded pistol. You know they're going to hurt someone, you're just not sure who. There is no way random users are going to be able to write correct implementations. It's just not going to happen.
I believe I see the problem here. We are in danger of violent agreement. It appears that you are talking about a Mailet container whose implementation characteristics have very little in common with the current JAMES server. (Other than the handoff of a mail object to a mailet class.) Are you proposing that a framework be provided that would make the writing of a custom Mailet container a relatively simple exercise? Or that a lightweight container actually be implemented? I would certainly be happy with either of these.The mailet API allows us to maintain a very strong and clear abstraction barrier between the SMTP service implementation and the post-SMTP mail processing. That ensures that James administrators do not have to concern themselves with the details of the SMTP transaction, while retaining all of the mail-processing power.
Things that I would not be satisfied with include:
* Embedding anything as big as JAMES.
* Embedding my app inside JAMES (well - Avalon).
How would you envisage that the socket listener bit fitted in? Would it all be bundled? How would its thread handling work? (Would it have it own code for creating/managing threads, or would that be provided by the app embedding the container? Or am I missing the point again?
Ok. The making money statement comes across as pretty cynical. The point that I wished to make was that *a* solution was provided to *a* problem, as opposed to *the* solution to *the* problem.Hmmm. Message Beans exist because J2EE server exponents figured that there would be enough interest to make them some money - not because they figure it was the only solution to the problem. J2EE appserversdonot preclude the usefulness of other solutions.Bah. This is a ridiculously cynical view of an engineering problem. I could make exactly the same statement about SMTP, JSSE, or JMS for that matter. It would be equally cynical, equally true, and equally irrelevant.
"basically undeniable" is a dangerous term to use. Yes, Message Driven Beans fill a gap in the market. No, they are not the only way to usefully implement a *real* JMS message driven application. How can anyone possibly contend that?No one is contending that this is the only solution to the problem - what is being contended is that it is a standard solution to a recognized problem. It was the act of providing a solution to the recognized problem that generated money for the container providers. The point remains that JMS was insufficient for the needs of real applications precisely because it lacked any lifecycle support. This is basically undeniable. Lightweight lifecycle support was added, and suddenly JMS became much more useful.
And the SMTP dialog handler, which - as you have mentioned previously - is pretty difficult to write from scratch.What would we have left if we stripped away the lifecycle elements of the Mailet API? IMO, we'd basically be left with the MimeMessage class of JavaMail. So what would be the point of defining a more limited API? What tasks would one hope to accomplish that could not be accomplished with the JavaMail classes?
Again, we're not talking about app servers. We're talking about the concept of a container. Very different. Please try and get clear on this. You do not (and will not) need an app server to run mailets. What you will need is a mailet container.
Crystal. Cheers ADK -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
