Should we move to Loom? I've tested it today and the changes I had to do in order to run inside Loom have been: 1) remove all the spaces from XML: loom does not automatically remove spaces so leaving the spaces in the config means misconfiguration. 2) change the data-source configuration to use org.apache.avalon.excalibur.datasource.JdbcDataSource instead of org.apache.james.util.dbcp.JdbcDataSource. It seems that newer excalibur jdbcdatasource already has integrated pooling and we could avoid using DBCP at all.
The advantages for the changes are: 1) Loom has a newer phoenix codebase and we get BETTER classloading: in fact loom already add SAR-INF/lib and SAR-INF/classes to the whole james application and we could entirely remove that "workaround" from the Mailet/Matcher Loader. 1a) In Loom you can configure a custom tree of classloaders 1b) In Loom you can provide policies to restrict the available resources 2) Loom has configuration validation 3) Loom has hot deploy/undeply of applications. 4) Maybe Loom has support for persisted configuration changes (I have to investigate on this) What are the disadvantages? 1) Loom is not a "solution" because it is not been developed in the last 6 months and it isn't final too. 2) Loom does not support full avalon 4.3 features (like hot reconfigurability) but I think no avalon container currenlty provide this feature. 3) Is a new container and we know it less than phoenix (most of the code is identical) 4) .... Please complete/ add your own .... Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
