Dear Wiki user, You have subscribed to a wiki page or wiki category on "James Wiki" for change notification.
The following page has been changed by SergeyLubinskiy: http://wiki.apache.org/james/SummerOfCode2005/SergeyLubinskiyFastFail ------------------------------------------------------------------------------ === Proposed solutions === Following FastFail proposal by DannyAngus and NoelBergman I intend to implement a drop-in replacement for - [http://james.apache.org/javadocs/org/apache/james/smtpserver/SMTPServer.html SMTPServer] block - the _New_SMTP_Block_. + [http://james.apache.org/javadocs/org/apache/james/smtpserver/SMTPServer.html SMTPServer] block - the __New SMTP Block__. - The _New_ _SMTP_ _Block_ will be close in design to + The __New SMTP Block__ will be close in design to - [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager]. + [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager]: + * [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager] hosts a family of ([http://james.apache.org/javadocs/org/apache/mailet/Matcher.html matcher] [http://james.apache.org/javadocs/org/apache/mailet/Mailet.html mailet]) pairs + * The _New_ _SMTP_ _Block_ will host a sequence of ./ProtoclLet s. - [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager] hosts a family of ([http://james.apache.org/javadocs/org/apache/mailet/Matcher.html matcher], [http://james.apache.org/javadocs/org/apache/mailet/Mailet.html mailet]) pairs. + === POJO/JMX/XML Configuration Convergence === + One of the key features of the proposed ./ProtoclLet desing is a rich runtime configuration model. + The _New_ _SMTP_ _Block_ will both be able to + * read/write XML configuration to disk + * provide JMX setter/getters for the complete configuration of each ./ProtocolLet + * provide JMX operations for reordering ./ProtocolLet -s, taking them down and creating new ones - The _New_ _SMTP_ _Block_ will host a sequence of ./ProtoclLet s. + All of metadata about ./ProtoclLet will be extracted by java introspection. Both XML format and JMX interface will be derived products. - Technically however it is going to be a bit different. + === ProtocolLets As A New Kind Of Components === + Like [http://loom.codehaus.org/Component+layers regular phoenix blocks] ./ProtoclLet -s will be able to depend on other Blocks inside James Phoenix Application. + === Future Directions === + If timeframe permits I may try to implement integration with scripting languages. There's nothing impossible in "protocolLets" being written in beanshell, jython, javascript. - Firstly I intend to allow re-configuration, reordering, addition and removal of "protocolLets" via JMX. To facilitate this I'm going to find a way to map: - * "protocolLets" bean-style configuration interface - * JMX allowed CompositeData and TabularData - * XML representation thereof (xstream-style) - * possibly Phoenix configuration objects - onto each other. - - As configuration of "protocolLets" and their order is changed via JMX this immediately affects the running block - in fact I imagine that we would take down "protocolLets" configured with old values and instantiated "protocolLets" with new configuration to avoid concurrency issues. Same applies to the protocolLet[] array representing their sequence. Each protocolLet is going to be stateless and thus tread-safe. Perhaps we can design JMX configuration interface so that all the reordering and reconfiguration will take effect in a batch as partially configured "protocolLets" may cause server failures. - - A key point here is to let the "protocolLets" see other blocks visible to the new SMTP block itself. This will simplify implementing such features as communicating outer processes (perl-written policies taken from postfix) or talking TCP to outer world hosts (RBL) - none of these actions actually belongs to "protocolLets" - little stateless decision makers. - - Then I'm going to add a JMX method for saving this configuration on disk. (Does Tomcat do that already?). - One interesting possibility would be to allow new SMTP block to save directly to SVN - thus making - provision for possible failures. - - If timeframe permits we may consider doing beanshell integration - there's nothing impossible in "protocolLets" being written in beanshell, or probably jython, javascript. In this case the code of the "protocolLet" becomes its configuration. I believe that this "go from getter/setters via JMX CompositeData to XML will let some fresh wind into the old dynamic server reconfiguration problem. + - Technical implementation of these features still needs to be explored. In essence "protocolLets" are quite similar to blocks but Phoenix machinery most likely can not be reused as it is. I see the following options to investigate and choose from: - * go for some quirks and tricks and make use of existing Phoenix internals as they are - * create a patched Phoenix (and push for new version being rolled out with these patches) - * run.. say Fortress inside new SMTP block (I'm trying to pick a container living inside ASF) - * DIY container plumbing pico-container style (shouldn't be too much code) closely along the lines of the current [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager] implementation === Advantages for ASF === - * A solid foundation for implementing a feature heavily demanded by current internet realities - SMTP fast fail - * Possible a new insight on the issue of reconfiguring components inside IoC containers + * A solid foundation for RBL/SPF/white-gray listing/Plug-In-Yours FastFail spam blocking + * Possibly a new insight on COP via POJO/XML/JMX configuration convergence === Deliverables === Totally revamped drop-in replacement for the existing [http://james.apache.org/javadocs/org/apache/james/smtpserver/SMTPServer.html SMTPServer]. Possibly patches or pieces of coded targeted for ASF containers. @@ -75, +65 @@ After August 14 fix react to bug reports and requests for enhancements. If time permits look into integration with scripting languages. - === Appendix - Expected protocolLet interface === - (Subject to change) - {{{ - interface ConnectionHandler ( - RulesResponce onConnection(Socket) - } - - interface CommandsHandler { - RulesResponce Map getCommands() - } - - interface CommandHandler { - RulesResponce onCommand(...) - } - - interface MessageHandler { - RulesResponce onMessage(...) - } - - RulesResponse { - boolean getSuccess(); - SMTPResponseCode getSMTPResponseCode(); - DSNResponseCode getDSNResponseCode(); - String getMessage(); - boolean isResponseMultiline(); - } - }}} - - Which has been shamelessly compiled out of FailFast and [http://mail-archives.apache.org/mod_mbox/james-server-dev/200506.mbox/[EMAIL PROTECTED] "07 Jun 2005 message on server-dev”] -
