>> Look, it sounds like you really like JAMES and want to use JAMES, so go use >> JAMES <<
Tsk Tsk Andy. Just because someone says he likes some design features of a competing piece of software is no reason to be so dismissive. There are things I think I would like about using James, like its Mailet API. It seems a reasonable solution to the problem of what to do with an e-mail after it arrives. It's appears to be a flexible, AOP-like, all-Java way to build custom mail processing; i.e. scan it for viruses, scan it using Spam Assassin or other spam-detection methods, check for whether the recipient is a member of a hosted domain. store it or delete it, etc. There are things I don't like about James, like its reliance on the now-defunct Avalon server framework instead of the well-known JMX and J2EE APIs. However, I would caution against dismissing the James mail processing API (at least the design aspects like the interfaces) just because "it wasn't invented here". If there are sound technical reasons why you don't like the Mailet API, I would still welcome a rational discussion about the benefits and flaws of the Mailet API as it might be applied to the JBoss Mail Server. Since that's what this discussion has evolved to, I'm going to start a new thread soliciting views on the Mailet API's applicability to the JBoss mail server. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3870603#3870603 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3870603 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
