Does using groovy mean using nanocontainer as well? Lightweight containers are great. I personally think constructor dependency injection is the right way to go.
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]
