Serge recently posted a mail to server-user saying that a container switch was a minor concern of ours (or at least something to that extent). I disagree on this, I believe that we have to make a decission on the container issue, to both keep existing comitters interested and possible attract new skilled people.
I'll restate since it must have been unclear... WHICH new container we move to is not important at this phase of development since we have to change our current code to a bunch of POJOs.
The container issue is by far the one thing that is keeping myself from doing commits into James. I hate doing something today and having to redo it all over in a month or two.
I'm in the same camp.
I tried to follow the discussion on JamesNG a while back, but as I at that time had little knowledge of neither Groovy nor Spring, I did not comment.
I have now done some reading on the two subjects and believe that Spring is the way to go for James. My main concern on JamesNG (I know this is not Groovy related) is the CDI principle IMO this principle leads to constructor bloat if you want to have some properties with default values, and I believe we do.
The Spring framework's Java-Bean approach is IMO a way better solution to the POJO-ification issue.
How are you seeing JavaBean != POJO? I've always used them as synonymous, except JavaBean's also has weird setter propertyeditor API for setAsText stuff.
Now I have started to convert James into POJO's the Spring way (only James.java so far), but as I stated above I hate doing things over, so let us take a vote. Is it going to be SpringJames or JamesNG.
Could you explain what the differences are?
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
