Hi Eric, I don't expect the pure-spring deployment to take more memory then the phoenix deployment do when its complete. So stay tuned...
Bye, Norman 2009/12/26 Eric MacAdie <e...@macadie.net>: > I do not mean to rain on anyone's parade, but I do have one concern. I am > running James on a VPS host with about 256 MB of memory, and right now James > uses about 50 MB or so. I noticed from > http://people.apache.org/builds/james/nightly/bin/ that the Spring version > is twice as big as the Phoenix/Avalon version. I do not have a lot of memory > to spare on my VPS account, and I would prefer not to upgrade (I am looking > for a job and money is tight). > > If James with Spring slows stuff down, I may have to look for something else > to handle email. Maybe I am making a big deal out of nothing, but a cursory > glance makes it appear that size may be an issue. Other than that: +1 > > Regards, > Eric MacAdie > Pronounced: muh-KAY-dee > > Norman Maurer wrote: >> >> Hi all, >> >> as you all prolly know I tried to decouple james in the last couple of >> weeks from phoenix / avalon as much as possible. This task is now >> complete and James should "just work" within every container / >> framework which understand howto handle jsr250 injections. I thought >> about using OSGI + Karaf as container for James but I think that would >> require many reorganisation within the code to get it work like it >> should. So while using OSGI is prolly not the worst move to attract >> more users / developers I'm still not 100 % sure if its really a good >> idea at all. >> >> At the moment I tend to just remove the Avalon-Guice Adapter classes >> which I create for every component and let just handle spring the >> injection stuff. The Log and Configuration injection will get done via >> Spring by using a BeanPostProcessor (like its done in the current >> spring-avalon-bridge). >> >> So anyone against this "radical" move ? >> >> Bye, >> Norman >> >> Ps: This would eliminate the use of Guice again too >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org