Joachim raeger wrote:
Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
BTW: if everything runs well with Spring, which advantages brings us
staying with phoenix, apart from backward compatibility with custom
code?
+ everyone in the dev team knows Avalon/Phoenix
+ it is proven to run James components in a stable production-ready
manner (we don't know yet which Spring-related and
not-running-in-Phoenix-related problems we will run into. this would
be the first painless migration in my career.
:-)
+ we still support Java 1.4, we should continue to support Phoenix
I completely agree. But we can keep in mind that this are all "soft" or
maybe non-functional arguments. I mean there is no important feature of
phoenix currently missing in spring.
Joachim
I don't use it, but phoenix has an optional Beanshell based kernel that
you can access with a console to manage the container and the contained
applications dynamically.
Phoenix has an HTTP adaptor on the ServiceManager that should allow you
to access the JMX services via web: we never really used this, but this
is in phoenix.
Phoenix supports autodeployment of new sar copied in the folder.
Phoenix supports classloader isolations between multiple applications
deployed inside it: I, as an example, have one single phoenix where I
deploy 3 different james instances.
Phoenix has some support to use RMI to control the behaviours of the
container (not sure anyone out-there is using this).
We (Norman) wrote a phoenix-daemon-loader that allow us to bind "<1024"
ports under unix and switch to an unpriviledged user: we would have to
write something similar for spring.
I don't know if spring provide any or multiple of this: This is to say
that there is not too much that keep us from going away, but there is
not too much that we gain leaving phoenix.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
