Aaron, > I agree that having both the mailet container and Avalon trying to > manage lifecycle would be bad. But that makes it no less desirable to > allow mailets to have access to Avalon services. On reflection, this > could as easily be achieved by having a Mailet that delegates its mail > handling to another Avalon component. I suspect that trying to wrench > JAMES around to do this for me would not be good for me or JAMES. (I > wonder how easy it would be to write a generic handoff mailet?)
I don't have any idea what you mean by a "generic handoff mailet". It is trivial to write a mailet that uses Avalon components. I described (in some detail) how exactly one would do that in some of the earlier emails in this thread. > Unless I am mistaken, embedding a mailet container in order to run a > single mailet would still involve configuring a root processor with an > all matcher for my mailet. You are mistaken. Write your own container and no root processor is necessary. The processor tree is an implementation-dependent construct, not fundamentally part of the Mailet API. All the API dictates is that the mail message being processed has a "state". The associate of that state with a spoolmanager processor is a product of the implementation. > The "administrative overhead" I am refering to is the overhead of > writing (and maintaining) a configuration file for the processor. If I > don't need matchers and mailet chains, why configure them? Then don't put them in your container. > An I simply mistaken in my expectation that processors, matchers and > configuration files are necessary to an embedded mailet container? Bingo. You are mistaken. > > I'm not going to comment on the design issues that you and your team may > > face, except to say that backwards compatibility with your apps should > > not and cannot be a factor in our API design. > > Of course not - that is why I have not made any attempt to justify or > even describe my design. It is simply not relevant. What I am talking > about is widening the applicability of JAMES to include another possible > deployment scenario. My personal view is that this is a generally > useful thing. (You obviously do not agree.) I don't think the deployment scenario you describe is left uncovered by the current API or any proposed API we're likely to come up with. I think I've been pretty clear on this one. And I think the solution you propose is extremely dangerous and underestimates the difficulty of writing a correct, robust SMTP dialog handler. To put this in some perspective, prior to this version James has never matched the basic SMTP specification. Even with version 2.1 there are some known issues (minor bug in dot stuffing) and deliberate violations (lack of support for certain SMTP commands) in place. 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. 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. > This is not entirely accurate. As mentioned above, it is not really > even relevant. To me, this discussion is about the best way of > embedding support for mail receipt into an application. Your contention > is that I should embed an entire mailet container. My contention is > that I just want the minimum code possible to turn an SMTP conversation > into a Mail object. And what exactly do you think is the gap between these two? > Speculation about whether or not *I* need lifecycle support is pointless > unless you want to get specific to my own application. (I can't see why > you would.) Our point of contention is whether or not full lifecycle > support is so useful that it precludes the usefulness of embedding mail > support without lifecycle. The lifecycle is deliberately lightweight. That's one big reason not to incorporate the entirety of the Avalon lifecycle. There is a complete discussion of the Avalon lifecycle here: http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html To contrast the Mailet API lifecycle would include equivalents of phases 1,2,3,4,6, and 14. These phases need not necessarily be separated in the same way in the Mailet version, but I think there is general concurrence that we need the same functionality. So what would you toss away? What phase is unnecessary? Moreover, what phase is expensive? If your mailets are so trivial that they don't need configurations, initialization, etc. then why begrudge a couple of method calls? If they do need one of those phases in place, then they wouldn't be usable in some hypothetical Mailet API w/o lifecycle code. What exactly is the benefit here? > > > > > Let's be clear - message beans exist because the JMS API was > > insufficient to meet the needs of most applications. There needed to be > > a way to bring message response under the management of the container. > > That's why message beans exist - it was a common problem that now has a > > standardized solution. > > 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 appservers do > not 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. 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. 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? > > > > In a J2EE container you do not have access to the raw message stream. > > That's because you give up low level access to the message in exchange > > for the power, good design, and control of a container. All good stuff. > > Yes great stuff - but not a silver bullet. Appservers are not the > universal solution to all coding problems. Unfortunately, they are > treated as such by many people. (I hear that there is even an appserver > about that runs in a mobile phone!) 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. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
