Aaron, > *Avalon dependencies* > > I understand and agree with the objections to Avalon dependencies in the > mailet container. I think that JAMES should continue to use Avalon, but > care should be taken to ensure that the JAMES design is not not infected > with dependencies on Avalon. Rather, the JAMES _implementation_ of the > mailet container should _use_ whatever avalon services it finds useful. > Similarly, in my mailets, I should not be _required_ to make my mailet > into > an Avalon block, but I would like to be able to. (I guess this is > probably > harder than it sounds, but it would still be nice.)
This is actually a typical server anti-pattern. Essentially, it ignores the inversion of control idea. Inversion of control inherently implies a chain of command (and hence a top of the chain of command). If you have two managing containers (and hence two responsible parties) you have two competing tops of the chain of command. Ordering problems, initialization and disposal issues, etc. result. Very contrary to good server design. See this link for more info: http://jakarta.apache.org/avalon/framework/guide-patterns-ioc.html > > *Mailet Container vs MailListener* > > My objection to having to embed the entire Mailet container is not a > particularly strong one - if I have to embed the whole thing, that will > not > be the end of the world - but here are a few reasons: > * Using a mailet container implies configuration of processors, > mailets, etc. This is an administrative overhead that is simply > unnecessary if you are not using that functionality. Uh, we still haven't identified this supposed "administrative overhead" that you'd be able to dispose of. I think we're on a snark hunt. Take a look at the spoolmanager code. Ask yourself exactly what you'd cut out. And what exactly you'd gain. > * Writing to spool implies that you must provide a place on disk > to > write to info. Not the end of the world, but again - unnecessary. An > in-memory spool manager implementation would help here. No, it doesn't imply that at all. As your 2nd sentence points out, there is nothing to prevent you from implementing an in-memory spool. Or a spool that provides storage in any other way you want (networked file system, punch cards, audio-encoded, what-have-you). Honestly, if you really, really wanted to, you could write a spool repository implementation that directly accepted messages from the SMTP service and synchronously passed them to your favorite mail processing (be it Mailet or otherwise) tool. It wouldn't necessarily be a particularly good idea, but you could do it. The current implementation requires the above, but that's because the James user and developer base hasn't had a compelling reason to develop alternate spools. If you want to, please feel free to write some local filestore independent spool implementations. That solves this problem. > As far as life cycle issues go - yes lifecycle support for mailets is > important. There are many cases, however, where an application will have > its own way of addressing these issues. When a requirement then crops up > to start receiving mail, I do not want to be forced to by in to a whole > new > design approach, (however good it may be,) just to do this. Uh...you're not. I think that much of your confusion on this topic is due to a general misunderstanding of features available through the Avalon framework and through Phoenix. Please take a careful look at the Avalon and Phoenix docs. I've already given an overview in my earlier responses about the proper way to do in-process communication. Major APIs are already supported (i.e. EJBs via OpenEJB) and Tomcat support is underway. Running custom servers where you don't want to expose an component interface inside Phoenix is literally a piece of cake - it's just a wrapper for a well written server. I've done it a couple of times already. 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. >From what I can tell, you've got a handoff from the James process to your EJB engine that you don't like. There are two realistic options to address this - either deploy James inside your J2EE container or deploy your J2EE container inside Phoenix. Adding interceptor APIs at the level you propose is not only unnecessary, but it doesn't actually get you anywhere in solving this problem. > To address Peter's comments about listeners vs managed components: The > JMS > API *does* give you the opportunity to receive JMS messages without > implementing a MessageDrivenBean. This is an excellent analogy. I am not > forced to do the whole J2EE appserver thing in order to use JMS. I can if > a want the whole lifecycle thing, but I don't have to. That is the point. > JAMES restricts developers to the appserver approach (JAMES being the > appserver, in this case,) instead of giving the flexibility. This is not > necessary. This is just historically and factually inaccurate. 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. 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. The mailet API as currently designed, and as likely to be modified in the future, does not require an app server. It requires a container. There is a big, big difference. Tomcat is a servlet container, but it is not an app server. There has been nothing in the API that would prevent you from writing a mailet container inside Tomcat. Similarly, Merlin is an Avalon-Framework container that is designed to be embeddable. Stephen McConnell has been playing with running James in this embeddable container. Merlin could be embedded in Tomcat, and who knows what else. That's much of the point of Merlin. So what flexibility don't you have? IMO, none. What do you gain? - easy, standardized configuration and an organized lifecycle. > I hope I am not harping on about this subject too much. I just seems like > the right time to discuss it, leading up to v3. Nope. I still think this whole pov is wrong though. I found the "Mailets v3" email to be a much more interesting and productive email. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
