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 ------------------------------------------------------------------------------ Technically however it is going to be a bit different. - Firstly I intend to allow re-configuration, reordering, addition and removal of "protocolLets" via JMX. To facilate this I'm going to find a way map + Firstly I intend to allow re-configuration, reordering, addition and removal of "protocolLets" via JMX. To facilate this I'm going to find a way to map: - * "protocolLets" bean-style configuration interface + * "protocolLets" bean-style configuration interface - * JMX allowed CompositeData and TabularData + * JMX allowed CompositeData and TabularData - * xml representation thereof (xstream-style) + * xml representation thereof (xstream-style) - * possibly Phoenix configuration objects + * 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 instantiate "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. @@ -58, +58 @@ I beleive 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 opitions to investigate and choose from: - * do so quirks and tricks and make use of existing Phoenix internals as they are + * do so 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) + * create a patched Phoenix (and push for new version being rolled out with these patches) - * run.. say Fortress inside new smpt block (I'm trying to pick a container living iside asf) + * run.. say Fortress inside new smpt block (I'm trying to pick a container living iside 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 + * 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 -
