Any consideration on using HiveMind as the container? Albert
--- Gabor Kincses <[EMAIL PROTECTED]> 內容： > 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] > > > > > > > ===== > === message truncated === ===== Are you an MBA? Check out http://www.mba.hk for value added services. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
