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

Reply via email to