Does using groovy mean using nanocontainer as well? Lightweight containers are great. I personally thinkJamesng is just an attempt to move james away from avalon, for now the configuration and amount of components is not too large to use nanocontainer.
constructor dependency injection is the right way to
go.
So I decided to use a single groovy script to integrate all components together. Well I have to say it is becoming more complex so maybe we should move to nanocontainer, but for now i dont use it.
Any suggestions, code contributions are welcome.
Check out the DummyConfig.groovy (the default config for the jamesng using DummyUserStore and maildir as storage) to see for yourself how all components are assembled, configured and started.
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3
Answering your question: yes, lightweight containers are great and nanocontainer is great as well, but the configuration is so lightweight for now that even nanocontainer seems to be an overkill.
You are more than welcome to prove me wrong.
Thanks, Gabor
--- Alexander Zhukov <[EMAIL PROTECTED]> 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]
===== Gabor Kincses Running Mandrake Linux 10.0
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
