On 10/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Bernd Fondermann ha scritto: > > On 10/8/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > >> I will go on record that I oppose a move to Spring, and have said so on > >> multiple occassions. However, I do not oppose optional support for Spring. > > > > The Phoenix deployment will live on. All the users having their own > > components and whatever customizations will be supported. For new > > users starting to use James there is no fundamental advantage chosing > > one deployment over the other. Except if they already have Spring > > components (or POJOs) they'd like to integrate with. > > It will take a bit for spring to catch up with all the features our user > may currently use in our phoenix deployment.
That's right. At the same time it offers, IMHO, ease-of-use and integration capabilities the phoenix deployment does not provide. > The spring deploymnet will need the scripts for unix and windows, the > wrappers to run it as a service, it will need the integration with > Commons Daemon. Agreed. > As an example of phoenix advanced components, phoenix provides a > Beanshell based kernel that you can access with a console to manage the > container and the contained applications dynamically. Phoenix is a very mature and capable container. Spring cannot supersede every possible feature of Phoenix or any other technology. And I am not saying that Spring is equivalent to Phoenix in every single example you gave. But nevertheless, I'd like to give some references where everybody interested might start reading... for scripting and BeanShell support, see Spring Reference Chapter 24. esp. 24.3. > Phoenix has an HTTP adaptor on the ServiceManager that allow you to > access the JMX services via web. see Spring Reference Chapters 17.4 and 20. > Phoenix supports classloader isolations between multiple applications > deployed inside it Spring does not offer that, AFAIK, but if you already have separate classloaders, you can have one BeanFactory for each. So it does not offer classloader isolation, but supports it. > Not everything in this list will make me veto a proposal to use spring > as our main deployment and forget about phoenix, but some of them are > important, and this was mainly to make it clear that spring is not the > panacea. Alright. My basic idea behind the spring-deployment is /choice/, to offer our users new ways to integrate James with their own or third party software. Pheonix-deployment module will live on as long as someone is maintaining it. At least I myself will never propose to deprecate it. > OT: In almost an year we didn't add anything SMTP/POP3 related > neither improved our support for mailets (this is not a critic to you or > your cool spring module, but something our PMC should take into account) yes, but I don't see the protocols as the only important part of the server. working at the fundamental architecture and making it more manageable will also open up new opportunities to innovate in the protocol section. Service interfaces could also be improved. For example, with the new modularized project layout we could have two SMTP implementations side-by-side, one proven, one experimental - just like we seem to have two different deployments. I'm not an expert on mail protocols, so I'll work on other parts of the project. Bernd > > Stefano > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
