> - Restart for every conf change. I took a long hard look at dynamic reconfiguration a while back and came to the conclusion that it was primarily the Avalon container that would have to support this, but Phoenix did not. In addition, the Mailet API would need to be extended to provide parallel support for Mailets as they are not components in the Avalon sense.
> - All in XML files (or worse, a database) I personally see nothing wrong with the configuration being stored in XML files. The problem lies in the lack of tooling to manipulate the configuration. A JMX based administration console would be great, but again this is primarily an Avalon container responsibility, and Phoenix isn't quite there. > Troubleshooting Sure there is room for improvement, but James is hardly the most obtuse of environments I've worked in. > - No consensus on how to support more complex processing > logic (matcher > params, BSD scripting, etc...) Yes, the matcher/mailet syntax issue does need to resolved. BSD? Do you mean BSF? If so, that's done but won't be easily usable until a more flexible matcher syntax is agreed. > At the same time, we get questions about extracting protocol > handlers, > embedding in JBoss or other apps, and otherwise componentizing James. Many of the requests to embed James in a J2EE server or other apps. tend to be written with the assumption that this is the only way their app. can interact with James. More often than not, the desired interaction can be achieved without such embedding and with greater security and stability too. Most of the requests for extraction of protocol handlers seem to be based on the idea that James has some great code that could be used in another application if only we had not written it for our application. Sorry! What is most important to me? Dynamic reconfiguration and administration. Maybe the best route is to improve Phoenix, maybe it means switching containers, possibly to Merlin. What ever it takes. Thats my two pennies/cents/roubles worth. -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
