I dont say avalon is bad I just think CDI approach is more scalable and easier to understand. To form your own opinion please refer to Martin Fowlers article "Inversion of Control Containers and the Dependency Injection pattern"Hi!
I am new to the list. I see that avalon dependency received couple of critics on the list. Why is avalon 'bad' and what is the intention of the james team with this?
http://www.martinfowler.com/articles/injection.html
Among benefits of CDI IoC is high level of component decoupling that is your components may not depend on each other or have any requirement that is a show-stopper to include your component into the software you are developing.
Laszlo
Alexander Zhukov wrote:
Hi, James hackers!
Recently on the mailing list I saw messages of departure from avalon-based container
So i decided to propose my ideas and reference implementation as a basis of next generation james
(i hope avalon-free version) which i propose to call jamesng
nice points in jamesng for apache james are: - components are independent POJOs (CDI IoC) so no funky interface has to be implemented to extend james-ng (see COMPONENTS) - single file groovy-based configuration - multiple domains support from the ground up - adaptable user stores (enterprise does not want to change its db/ldap directory/whatever) (see ENTERPRISE DB) - javax.mail.Store/Folder based mail repositories support hierarhical folders, tested with Maildir and mbox providers (see STORES) - extensive support for folder/store/user caching to speed-up servers (see CACHING) - imap4 support (not complete but usable) - pop3 support - independent components can be easily added and integrated into build system
things laking: - smtp support - no spooling/remote deliveries, working on it right now
ENTERPRISE DB
server is large ISP/enterprise targeted which means
- support for multiple domains on a single/multiple IP addresses,
- highly configurable user stores - database should not be designed for use with james (as it is with current james)
but rather user store adapts to the existing userstores of an isp/enterprise.
Often enterprises already have their user databases often they contain legacy elements which such companies
just very much hesitate to change to something new.
Above mentioned is very much true for LDAP directories - you cannot expect an enterprise to change its
LDAP directory to fit james in
COMPONENTS
All components of james-ng are POJOs no component _must_ implement some funky interface to be included in the server.
Components adhere CDI style IoC which besides other advantages allows configuration to be a single groovy file.
The task of groovy configuration is to assemble all components together.
STORES
Mail stores (repositories) are plain javax.mail.Store providers.
Since javax.mail.Folder interface supports hierarchy james-ng gets "free" IMAP support - no need to reengineer mail
repository to access folders/sub-folders. However to support all of IMAP features such provider's Folder implementation
must as well implement UIDFolder interface to support IMAP UID operations.
For now tested are Maildir and mbox providers, but apparently nothing prevents to write/use existing jdbc providers
that would store mails in database.
Simple groovy-based configuration allows administrator to configure different types of stores for different users.
CACHING
I am currently in charge of rather large (150k+ users) free webmail with multiple domains
and i dont have very new and high-performing hardware to host it so i designed the server for performance.
The main point is to avoid unproductive waste of performance (very much true for most unix mail servers)
stores/folders opened by users as well as user objects are cached (certainly you can turn the cache off) instead of being
open on every user login. Very much helps for polling clients which disconnect and connect back in 10 minutes.
Administrator can adjust the caching policy, for now implemented are LRUCache and GCCache (reference map based cache).
If you are reading this then you are ready to see what does jamesng look like.
Since the codebase is pretty large for an attachment to email I have setup cvs repostitory as well as source release repository.
Source release: http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz Binary release http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
I suggest you download source release and build binary release or just download binary release to play with the groovy
all-in-one configuration.
Anonymous CVS access: CVSROOT=":pserver:[EMAIL PROTECTED]:/export/cvsroot/jamesng" anoncvs user has empty password
FishEye (like viewcvs but better and in java)
http://devel.priocom.com:8083/viewrep/JamesNG
You can also download the latest cvs checkout tarball at
http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
As steps further steps to develop apache james i propose:
- create a new branch in svn called "JAMES_NG" or the like
- give up using avalon container in this branch
- either use one of the existing CDI containers (picocontainer) or accept proposed groovy-based config files
- merge smtp/mailer/mailet code into JAMES_NG branch
- use the branch as a basis for James v3
Any ideas? Flames? What is wrong with my approach?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
