james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara" <apa...@bago.org>
Subject Switch to Loom 1.0RC3
Date Tue, 06 Sep 2005 22:49:05 GMT
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
3) Is a new container and we know it less than phoenix (most of the code is
4) .... Please complete/ add your own ....


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message